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CROSS REFERENCES TO RELATED APPLICATIONS 

The present application is a continuation-in-part of co-pending U.S. Patent 
Application No. 10/135,191, filed April 29, 2002. .The entire contents of the above 
application are incorporated herein by reference in entirety. 

5 BACKGROUND OF THE INVENTION 

The typical insurance system includes a quotation phase for insurance coverage, 
followed by preparing and writing insurance contracts requested by clients. Insurance 
quotation, and creation of contracts has traditionally been paper based. 

The insurance process is further burdened with an underwriting function also 

1 0 conducted by manually reviewing and evaluating voluminous and redundant client 

information and application forms. Forms for insurance products are normally supplied 
by individual insurance providers or agents and must be revised periodically in response 
to changes in the client's information or legislative enactments in the state in which the 
insured risk resides. Typically each insurance transaction, application or request for • 

15 information requires a separate document to be filled out by the client or agent. Due to 
the general nature of creating, and maintaining redundant information in the forms a 
tremendous volume of paper needs to be managed. The paper based systems and 
processes for insurance contracts are inefficient and time consuming for all involved, 
the client, the insurance agent, the provider and the insurance agent. 

20 The manual review and voluminous evaluations are being replaced by 

computerized systems that address different phases of the insurance process. In 
particular computerized systems exist for some portions of the quotation request phase 
and some portions of the enrollment phase of the insurance process. 

However, there still remains a need to improve the systems and methods for 

25 providing insurance products. 

SUMMARY OF THE INVENTION 

The system and method of the present invention includes an integrated insurance 
system for automating information processing and computerizes the quoting, 
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enrollment, billing, monitoring and maintenance functions of the process. The preferred 
embodiments of the integrated insurance system efficiently communicate with all 
partners in the business of insurance, using electronic exchange of information. 
In a preferred embodiment, the system of the present invention includes a 
5 quoting subsystem, an enrollment subsystem, a customer resource management 
subsystem. The system of the present invention further includes a vendor portal 
subsystem, a partner portal subsystem, a reporting subsystem, an electronic data 
interchange ((EDI) subsystem, an event triggering subsystem, a carrier management 
subsystem, a knowledge base subsystem, and a document management subsystem. The 

10 quoting subsystem in a preferred embodiment provides product choices, confirms 

demographic information, customizes a quote, accounts for employer contribution and 
provides a quote or a plurality of quotes. In a particular embodiment, an underwriting 
and eligibility subsystem is in communication with the quoting subsystem. The 
enrollment subsystem includes for selected product choices selecting available plans, 

15 accounting for employer contribution, confirming information using underwriting and 
eligibility subsystems and submitting information to a vendor subsystem. The contact 
resource management subsystem includes monitoring and tracking sales activity, 
customer service activity and finance activity. 

The vendor portal subsystem includes resources for a carrier partner to review 

20 account information, including, for example, but not limited to, enrolled groups, 

enrolled members, premium amounts, commission amounts and account activity, such 
as member additions, changes and terminations. The partner portal subsystem includes 
resources for third-party relationships to access applicable account information, 
including but not limited to, for example, prospect activity, enrolled groups, enrolled 

25 members, premium amounts, and commission amounts. The reporting subsystem 
includes, for example, resources to view defined reports with stipulations on content 
information that can be viewed by each group. The EDI subsystem includes, for 
example, functionality for sending electronic information to external parties in a 
predetermined format, including, for example, the ability to track the status of the 
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transmission. The EDI subsystem works in conjunction with the event triggering 
subsystem to determine the content and extent of information that should be exchanged 
based on predefined events. The knowledge base subsystem includes, for example, 
resources for tracking internal items and information which can be utilized by internal 
5 staff members to resolve complex issues. The document management subsystem 
includes, for example, resources for converting paper-based documents into an 
electronic form and for storing electronic documents in a centralized location in order to 
make the information contained in the documents more easily accessible. 

In another preferred embodiment, the system of the present invention includes 

10 automating the enrollment, billing and customer resource management subsystems. The 
billing subsystem includes at least one of a client billing subsystem, a vendor billing 
subsystem and a sales commission subsystem. 

In another preferred embodiment, the system of the present invention includes 
subsystems, for example, the enrollment subsystem, which are in communication with 

1 5 multiple databases having a data structure that includes multiple tables having a record 
structure that includes fields. The fields have data or keys that point to data stored in 
other record structures. These keys provide links to common data used by each of the 
subsystems, for example, the quoting, the enrollment, the billing and the monitoring 
subsystem. 

20 In a preferred embodiment, a system for creating and administering insurance 

contracts, includes a front-end subsystem in communication with a client, a database 
subsystem accessing a plurality of stored databases, and a back-end subsystem in 
communication with a plurality of subsystems to source information and monitor the 
creation, and administration of an insurance contract. The front-end subsystem 

25 communicates via a network such as, for example, the Internet, and is further operative 
with a set of executable instructions to collect contract information, from and deliver 
contract information to a plurality of clients. The front-end subsystem includes at least 
one of a set of executable instructions for quoting a plurality of terms of the contract, an 
enrollment process, a billing process and contract maintenance. The back-end 
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subsystem communicates with a network and accesses the databases. The back-end 
subsystem includes a system application having a quoting subsystem, an enrollment 
subsystem, a billing subsystem, and a resource management subsystem, and 
communicates with the front-end subsystem which in turn communicates with the client 
5 and an insurance carrier or vendor to communicate the creation, execution and 
management of the insurance contract to the client. In preferred embodiments, the 
back-end subsystem further comprises an underwriting and eligibility subsystem, a 
reporting subsystem, an archiving subsystem, and an electronic data interchange (EDI) 
subsystem. The front-end subsystem communicates with an insurance vendor. 

10 In accordance with another aspect of the present invention, in a data processing 

system, a method of implementing insurance contracts between a client and an 
insurance provider includes receiving a plurality of inputs for a quoting subsystem from 
the client, processing the plurality of inputs and generating a quote in response to the 
plurality of inputs, transmitting the quote to the client, executing the insurance contract 

15 and enrolling the client upon receiving an approval with respect to the quote, generating 
invoices that correspond to the contract using a billing subsystem, monitoring and 
managing the quoting subsystem process, a customer service process and the billing 
subsystem. 

The method further includes creating and storing in a database a plurality of 
20 contract templates or forms having terms and conditions of the contract. The method 

further includes reviewing eligibility and underwriting requirements upon receiving the 

plurality of inputs from the client. 

In accordance with another aspect of the present invention, a computer program 

product for implementing an insurance contract between a client and a provider, 
25 includes a computer usable medium having a computer readable code, including 

program code which receives a plurality of inputs from the client, processes the 

plurality of inputs, generates a quote, and executes the insurance contract by enrolling 

the client, monitors and manages the plurality of client inputs and generates 

corresponding invoices. 
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In accordance with a preferred embodiment the apparatus for implementing the 
insurance contract between a client and an insurance provider or carrier includes a data 
processor having multiple tables. Each table in the database has a record structure that 
includes fields having data or keys that point to data stored in tables. These keys 
5 provide links to common data used by the quoting, enrolling, billing and monitoring 
subsystems. 

In accordance with another preferred embodiment, the apparatus and methods 
for implementing insurance contracts include web-based information management 
systems, particularly for customer support. This web-based support can provide as a 

1 0 minimum comparative analysis of different quotes. 

In accordance with another preferred embodiment, the system includes a claim 
processing method that includes receiving a claim, checking the eligibility of the claim, 
adjudicating the claim electronically and then distributing the funds. The claim 
processing method uses a logging subsystem, the EDI subsystem, the event triggering 

15 and reporting subsystem. 

A preferred embodiment of the integrated system includes an automated method 
for processing an insurance claim. The method includes providing a front-end 
subsystem in communication with at least a client, an insurance vendor, or an insurance 
partner, a database subsystem accessing a plurality of stored databases; and a back-end 

20 . subsystem in communication with a plurality of subsystems to source information, 

monitor the creation, and administration of an insurance contract. The method further 
includes receiving a claim from a client using the front-end subsystem, validating the . 
eligibility of the claim by accessing the information in the plurality of databases, 
electronically adjudicating the claim; and sending authorization signals to a data 

25 processor in order to dispense the funds associated with the claim. 

The foregoing and other features and advantages of the system and method for 
insurance products will be apparent from the following more particular description of 
preferred embodiments of the system and method as illustrated in the accompanying 
drawings in which like reference characters refer to the same parts throughout the 
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different views. The drawings are not necessarily to scale, emphasis instead being place 
upon illustrating the principles of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic block diagram of the integrated insurance system in 
5 accordance with a preferred embodiment of the present invention; 

FIGS. 2 A and 2B are schematic flowcharts illustrating the customer 
resource/relationship management (CRM) process flow in accordance with a preferred 
embodiment of the present invention; 

FIG. 3 illustrates a schematic flowchart detailing the CRM process for the sales 
10 process in accordance with a preferred embodiment of the present invention; 

FIG. 4 illustrates a flowchart detailing the CRM process for the customer service 
process in accordance with a preferred embodiment of the present invention; 

FIG. 5 illustrates a flowchart detailing the CRM process for the finance process 
in accordance with a preferred embodiment of the present invention; 
1 5 FIG. 6 is a diagram illustrating the portal subsystems in accordance with a 

preferred embodiment of the present invention; 

FIG. 7 illustrates a schematic block diagram detailing the employer portal 
subsystem in accordance with a preferred embodiment of the present invention; 

FIG. 8 illustrates a schematic block diagram detailing the employee portal 
20 subsystem in accordance with a preferred embodiment of the present invention; 

FIG. 9A illustrates a schematic block diagram detailing the vendor portal 
subsystem in accordance with a preferred embodiment of the present invention; 

FIG. 9B illustrates a schematic block diagram detailing the partner portal 
subsystem in accordance with a preferred embodiment of the present invention. 
25 FIG. 10 illustrates a flowchart detailing the process flow in the quoting 

subsystem in accordance with a preferred embodiment of the present invention; 

FIG. 1 1 A illustrates a flowchart detailing the process flow in the enrollment 
subsystem in accordance with a preferred embodiment of the present invention; 
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FIG. 1 IB illustrates a process flow for the carrier management subsystem in 
accordance with a preferred embodiment of the present invention. 

FIG. 12 illustrates a flowchart detailing the process flow in the billing subsystem 
in accordance with a preferred embodiment of the present invention; 
5 FIG. 13A illustrates a flowchart detailing the process flow in the client invoicing 

subsystem which is included in the client billing subsystem which in turn is included in 
the billing subsystem in accordance with a preferred embodiment of the present 
invention; 

FIG. 13B illustrates a flowchart detailing the process flow for posting invoices 
10 which is included in the billing subsystem in accordance with a preferred embodiment 
of the present invention; 

FIGS. 14A and 14B illustrate a flowchart detailing the process flow in the billing 
subsystem, in particular the client payment process in accordance with a preferred 
embodiment of the present invention; 
1 5 FIG. 1 5 A illustrates a flowchart detailing the process flow for the billing 

subsystem, in particular the vendor billing subsystem in accordance with a preferred 
embodiment of the present invention; 

FIG. 15B illustrates a flowchart detailing the carrier remittance subsystem 
process flow as part of the vendor billing subsystem in accordance with a preferred 
20 embodiment of the present invention; 

FIG. 15C illustrates a flowchart detailing the carrier payment subsystem 
included in the vendor billing subsystem in accordance with a preferred embodiment of 
the present invention; 

FIGS. 16A-1, 16A-2, 16B-1 and 16B-2 are table diagrams used in the enrollment 
25 subsystem for the integrated insurance system in accordance with a preferred 
embodiment of the present invention; 

FIGS. 17A-1, 17A-2, 17B-1 and 17B-2 are table diagrams used in the billing 
subsystem and support tables in accordance with preferred embodiments of the present 
invention; 
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FIGS. 18A and 18B illustrate flow diagrams detailing exemplary interactions 
for the employer portal and the employee portal, respectively, in accordance with a 
preferred embodiment of the present invention; 

FIG. 19 illustrates a view of a display screen that a user interfaces with in order 
5 to allow an account executive to view which users have access to the system in 
accordance with a preferred embodiment of the present invention; 

FIG. 20 illustrates a view of a display screen that a user interfaces with in order 
to log into a portal and setup an account access in accordance with a preferred 
embodiment of the present invention; 
10 FIG. 21 illustrates a view of a display screen that a user interfaces with in order 

to view account information in accordance with a preferred embodiment of the present 
invention; 

FIG. 22 illustrates a view of a display screen that a user interfaces with to view 
quotes in accordance with a preferred embodiment of the present invention; 
15 FIG. 23 illustrates a view of a display screen that a user interfaces with in order 

to access the account as part of customer service menu option in accordance with a 
preferred embodiment of the present invention; 

FIG. 24 illustrates a view of a display screen that a user interfaces with in order 
to view the account information from within the CRM system in accordance with a 
20 preferred embodiment of the present invention; 

FIG. 25 illustrates a view of a display screen that a user interfaces with in order 
to view the invoices from within the CRM system in accordance with a preferred 
embodiment of the present invention; 

FIG. 26 illustrates a view of a display screen that a user interfaces with in order 
25 to view invoice details from within the CRM system in accordance with a preferred 
embodiment of the present invention; 

FIG. 27 illustrates a view of a display screen that a user interfaces with for 
viewing payments from within the CRM system in accordance with a preferred 
embodiment of the present invention; 
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FIG. 28 is a flowchart detailing the setup of a policy in accordance with a 
preferred embodiment of the present invention; 

FIG. 29 illustrates a view of a display screen that a user interfaces with in order 
to view a policy in accordance with'a preferred embodiment of the present invention; 
5 FIG. 30 illustrates a view of a display screen that a user (CSR) interfaces with in 

order to enter all pertinent information when adding a new policy in accordance with a 
preferred embodiment of the present invention; 

FIG. 31 illustrates a view of a display screen that a user interfaces with in order 
to map plans to a policy, in accordance with a preferred embodiment of the present 
10 invention; 

FIG. 32 illustrates a view of a display screen that a user interfaces with in order 
to assign sales roles as part of the enrollment process in accordance with a preferred 
embodiment of the present invention; 

FIG. 33 illustrates a view of a display screen that a user interfaces with in order 
1 5 to setup policy holders in the enrollment process in accordance with a preferred 
embodiment of the present invention; 

FIG. 34 illustrates a view of a display screen that a user interfaces with in order 
to list all the policies in the particular account and indicate different status in accordance 
with a preferred embodiment of the CRM/billing subsystem of the present invention; 
20 FIG. 35 illustrates a view of a display screen that a user interfaces with in order 

to setup or review the billing attributes of a policy in accordance with a preferred 
embodiment of the present invention; 

FIG. 36 illustrates a view of a display screen that a user interfaces with in order 
to display enrollment policy details in accordance with a preferred embodiment of the 
25 present invention; 

FIG. 37 illustrates a view of a display screen that a user interfaces with in order 
to display an override plan that is used to manually set a rate for a plan in accordance 
with a preferred embodiment of the present invention; 
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FIG. 38 illustrates a view of a display screen that a user interfaces with, in 
particular a customer to log into the system in accordance with a preferred embodiment 
of the present invention; 

FIG. 39 illustrates a view of a display screen that a user interfaces with in order 
5 to display customer specific information such as, for example, previous quotes and 
coverage profile in accordance with a preferred embodiment of the present invention; 

FIG. 40 illustrates a view of a display screen that a user interfaces with in order 
to display a client, in particular, a company profile in accordance with a preferred 
embodiment of the present invention; 
10 FIG. 41 illustrates a view of a display screen that a user interfaces with in order 

to display the employee profile and corresponding employee information in accordance 
with a preferred embodiment of the present invention; 

FIG. 42 illustrates a view of a display screen that a user interfaces with in order 
to perform a new rate comparison that includes the entering of company information in 
15 accordance with a preferred embodiment of the present invention; 

FIG. 43 illustrates a view of a display screen that a user interfaces with in order 
to enter employee information to perform a new rate comparison in accordance with a 
preferred embodiment of the present invention; 

FIG. 44 illustrates a view of a display screen that a user interfaces with in order 
20 to enter employer contribution to perform a new rate comparison in accordance with a 
preferred embodiment of the present invention; 

FIG. 45 illustrates a view of a display screen that a user interfaces with in order 
to display a comparison of all the plans offered in accordance with a preferred 
embodiment of the present invention; 
25 FIG. 46 illustrates a view of a display screen that a user interfaces with in order 

to display the comparison of the plan rate for each individual employee in a company in 
accordance with a preferred embodiment of the present invention; 
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FIG. 47 illustrates a view of a display screen that a user interfaces with in order 
to selectively remove certain plans from a quote page in accordance with a preferred 
embodiment of the present invention; 

FIG. 48 illustrates a view of a display screen that a user interfaces with in order 
5 to enroll in the integrated insurance system in accordance with a preferred embodiment 
of the present invention; 

FIGS. 49 and 50 illustrate views of display screens that a user interfaces with in 
order to enter all the pertinent information for an employer such as all the billing 
information for an employer in accordance with a preferred embodiment of the present 
10 invention; 

FIG. 51 illustrates a view of a display screen that a user interfaces with in order 
to enter a level of employer contribution in accordance with a preferred embodiment of 
the present invention; 

FIG. 52 illustrates a view of a display screen that a user interfaces with in order 
15 to enter employee information for each employee in accordance with a preferred 
embodiment of the present invention; 

FIG. 53 illustrates a view of a display screen that a user interfaces with in order 
to map employee plans in accordance with a preferred embodiment of the present 
invention; and 

20 FIG. 54 illustrates a view of a display screen that a user interfaces to display a 

list of employees with the corresponding forms which need to be completed for the 
enrollment process in accordance with a preferred embodiment of the present invention. 

FIG. 55 illustrates a view of a display screen that a user interfaces with when 
logging into the Carrier Management subsystem (CMS) in accordance with a preferred 
25 embodiment of the present invention. 

FIG. 56 illustrates a view of a display screen that a user interfaces with to filter 
the number of carriers in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. 
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FIG. 57 illustrates a view of a display screen that a user interfaces with to view 
the mappings between carrier, policy type and state in the CMS subsystem in 
accordance with a preferred embodiment of the present invention. 

* FIG. 58 illustrates a view of a display screen that a user interfaces with to add 
5 carrier mapping to policy type and state in the CMS subsystem in accordance with a 
preferred embodiment of the present invention. 

FIG. 59 illustrates a view of a display screen that a user interfaces with to edit 
carrier details in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

10 FIG. 60 illustrates a view of a display screen that a user interfaces with to edit 

carrier details in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIG. 61 illustrates a view of a display screen that a user interfaces with to edit 
carrier accounts in the CMS subsystem in accordance with a preferred embodiment of 
15 the present invention. 

FIG. 62 illustrates a view of a display screen that a user interfaces with to view 
plans in the CMS subsystem in accordance with a preferred embodiment of the present 
invention. 

FIG. 63 illustrates a view of a display screen that a user interfaces with to add a 
20 new plan in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIGS. 64 A and 64B illustrate views of display screens that a user interfaces with 
to add plans in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

25 FIG. 65 illustrates a view of a display screen that a user interfaces with to edit a 

plan in the CMS subsystem in accordance with a preferred embodiment of the present 
invention. 
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FIGS. 66 A and 66B illustrate views of display screens that a user interfaces with 
to edit plans in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

" " FIG. 67 illustrates a view of a display screen that a user interfaces" with to 
5 activate a plan in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIG. 68 illustrates a view of a display screen that a user interfaces with to view 
or edit regions in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. . 

10 FIG. 69 illustrates a view of a display screen that a user interfaces with to add a 

region and detailed information regarding a region in the CMS subsystem in accordance 
with a preferred embodiment of the present invention. 

FIG. 70 illustrates a view of a display screen that a user interfaces with to add 
counties that map to a new region in the CMS subsystem in accordance with a preferred 
1 5 embodiment of the present invention. 

FIG. 71 illustrates a view of a display screen that a user interfaces with to add 
region plans in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIG. 72 illustrates a view of a display screen that a user interfaces with to edit a 
20 region in the CMS subsystem in accordance with a preferred embodiment of the present 
invention. 

FIG. 73 illustrates a view of a display screen that a user interfaces with to edit 
the counties of a region in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. 
25 FIG. 74 illustrates a view of a display screen that a user interfaces with to edit 

region plans in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 
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FIG. 75 illustrates a view of a display screen that a user interfaces with to 
perform a mass update for a region's effective to dates and status in the CMS subsystem 
in accordance with a preferred embodiment of the present invention. 

FIG. 76 illustrates a view of a display screen that a user interfaces with to view 
5 or edit tiers in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIG. 77 illustrates a view of a display screen that a user interfaces with to add a 
new tier for a carrier in the CMS subsystem in accordance with a preferred embodiment 
of the present invention. 
10 FIG. 78 illustrates a view of a display screen that a user interfaces with to edit a 

tier in the CMS subsystem in accordance with a preferred embodiment of the present 
invention. 

FIG. 79 illustrates a view of a display screen that a user interfaces with to view 
or edit tiers in the CMS subsystem in accordance with a preferred embodiment of the 
15 present invention. 

FIG. 80 illustrates a view of a display screen that a user interfaces with to add 
qualifying events in the CMS subsystem in accordance with a preferred embodiment of 
the present invention. 

FIG. 81 illustrates a view of a display screen that a user interfaces with to edit a 
20 qualifying event in the CMS subsystem in accordance with a preferred embodiment of 
the present invention. 

FIG. 82 illustrates a view of a display screen that a user interfaces with to view 
plan rates in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

25 FIG. 83 illustrates a view of a display screen that a user interfaces with to update 

the activation of plan rates in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. 
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FIG. 84 illustrates a view of a display screen that a user interfaces with to upload 
plan rates files in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. 

FIG. 85 illustrates a view of a display screen that a user interfaces with to 
5 address imports that have not been completed in the CMS subsystem in accordance with 
a preferred embodiment of the present invention. 

FIG. 86 illustrates a view of a display screen that a user interfaces with to 
address an import rate in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. 
1 0 FIG. 87 illustrates a view of a display screen that a user interfaces with to 

address an additional step in the import rates process in the CMS subsystem in 
accordance with a preferred embodiment of the present invention. 

FIG. 88 illustrates a view of a display screen that a user interfaces with to 
address a further step in the import rates process in the CMS subsystem in accordance 
1 5 with a preferred embodiment of the present invention. 

FIG. 89 illustrates a view of a display screen that a user interfaces with to 
address an additional step in the import rates process in the CMS subsystem in 
accordance with a preferred embodiment of the present invention. 

FIG. 90 illustrates a view of a display screen that a user interfaces with to 
20 address plan documents in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. 

FIGS. 91 A and 9 IB illustrate display screens that a user interfaces with to 
upload and edit the information for plan documents on the server in the CMS subsystem 
in accordance with a preferred embodiment of the present invention. 
25 FIGS. 92 A and 92B illustrate display screens that a user interfaces with to edit 

the information for plan documents in the CMS subsystem in accordance with a 
preferred embodiment of the present invention. 

FIG. 93 illustrates a flowchart of a product support process in accordance with a 
preferred embodiment of the present invention. 
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FIG. 94 illustrates a flowchart of a claims process in accordance with a preferred 
embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The integrated insurance system is a fully integrated contact management, 
5 quoting, enrollment, billing, carrier management, electronic data interchange (EDI)- 
capable, auditing and tracking system for insurance products. The insurance coverage 
that the integrated system offers includes insurance for, but not limited to, medical, life, 
dental, short-term disability, long-term disability, property and casualty, automobile and 
homeowner's insurance. These products are directed towards groups and individuals, 
1 0 hereinafter described as employers and employees, respectively. 

FIG. 1 is a schematic block diagram of the integrated insurance system 10 in . 
accordance with a preferred embodiment of the present invention. The integrated 
insurance system can be divided into two systems: the internal system(s), designed for 
the employees who service the system, and the external system, designed for all other 
15 users that interface with the system 10. The internal system includes the customer 

resource management (CRM) subsystem 22, including all customizations, the reporting 
subsystem 24, the EDI subsystem 18, the carrier management subsystem 30 and the 
knowledge base subsystem 32. 

In a preferred embodiment, the external subsystems include the portals for the 
20 employer 2, employee 4 and vendor or carrier 6 that interface with the quoting or rate 
comparison, enrollment, and billing subsystems. Further, the external subsystems 
include the partner portal 40. Internal users make use of the CRM system 22, and have 
access to the external systems, while external users can only access specific sites, such 
as quoting and enrollment. The internal users can be subdivided along business lines, 
25 such as sales, customer service, product support, carrier relations, government relations, 
finance and quality assurance. The CRM system tracks all manners of tasks, electronic 
mail (e-mails), product literature and activities for the customers, vendors and carriers. 
The CRM system is integrated into each of the other modules. 
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In a preferred embodiment, the billing process is responsible for generating and 
tracking invoices and customer statements, generating and tracking customer payments, 
either in full or partial payments, generating and tracking commission on sales of 
premiums, either in full or partial payments, and generating and tracking payments to 
5 carriers, either in full or partial payments. Statements are generated each month for all 
active accounts. An invoice is based on the premium rates which are calculated when a 
company first enrolls and on any additional charges which may accrue while being a 
customer. Statements are based on one or more invoices which are generated for one or 
more lines of business. An invoice is based on the premium rates which are calculated 

10 when a company first enrolls. An enrollment period is typically one year. Each year the 
individual plan rate is updated based on new information received from the carrier. In 
general, a monthly invoice is composed of the plan chosen by each employee. Each 
plan has a rate which is determined by the carrier. When a payment is collected from an 
employer, a portion of the payment (known as the carrier remittance) is passed back to 

1 5 the carrier. The remaining portion is broken down to a commission and the company 
profit. The commission may be paid to an internal sales person, an external sales 
organization or a partner of the company: 

Monthly Statement = Total Premium Collected = Carrier Remittance + 
Commission + Profit. 

20 A preferred embodiment billing process flow is as follows: 



Table 1 



Generate 
Bills 


Each month the system generates invoices to the employer groups. 
These invoices are based on the plans (aka policies) setup by the 
employer group. 


Mail Bills 


The bills are mailed to the employer groups before the first of the 
month. 


Pay Bills 


The employer group sends a check to the insurance company or system 
administrators for the invoiced amount. 


Apply 
Payment 


When the check arrives, the payment is applied to the outstanding 
invoice(s). 


Release 
Funds 


If the invoice is paid in full, the invoice is marked closed and the 
payment is "released" to the carrier. 


Hold Funds 


If the full amount is not received, the invoice is marked "Pending" and 
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the funds are not paid to the carrier. If the invoice is not paid after the 
grace period (typically 30 days; however, the grace period is specific to 
the carrier), then the account is automatically "Suspended" and their 
1 coverage stopped. 

Those skilled in the art will readily see that the number of components of the 
insurance processing system 10 can be increased beyond what is depicted while 
maintaining the functionality of the processing system. The insurance processing 
system makes use of multi-user computer operating systems and network software 
5 which makes it possible to scale the capacity of the insurance processing system to the 
number of portals and the amount of processing activity. The insurance processing 
system includes a front end processing subsystem that comprises of portals 2, 4, 6, 8 to 
communicate with each party, be it an individual client (employee) 4, a group client 
(employer) 2, a carrier or vendor 6 or the system agents or service personnel who 

10 administer the functionality of the system. The system 10 includes multiple database 
data processors 16 to access and store a plurality of databases. The system 10 further 
includes a plurality of back-end processing subsystems such as, but not limited to, the 
electronic data interchange (EDI) subsystem 18, an underwriting and/or eligibility 
subsystem 20, the CRM subsystem 22, a reporting subsystem 24, an archiving 

15 subsystem 26 and a transaction logging subsystem 28, a knowledge base subsystem 32, 
an event triggering subsystem 36, a document management subsystem 34, an auditing 
subsystem 38, and a carrier management subsystem 30. 

In a particular embodiment, the insurance processing system 10 makes use of a 
computer network, such as the Internet 12 to link together portals, and subsystems 

20 interested in processing insurance contracts and products. The system application 14 
using a stored sequence of instructions communicates via the network 12 with each 
portal and each subsystem. * 

An operating environment for the system 10 of the present invention includes a 
processing system with at least one high speed processing unit and a memory system. In 

25 accordance with the practices of persons skilled in the art of computer programming, the 
present invention is described below with reference to acts and symbolic representations 
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of operations or instructions that are performed by the processing system, unless 
indicated otherwise. Such acts and operations or instructions are sometimes referred to 
as being "computer-executed," or "processing unit executed." 

It will be appreciated that the acts and symbolically represented operations or 
5 instructions include the manipulation of electrical signals by the processing unit. An 
electrical system with data bits causes a resulting transformation or reduction of the 
electrical signal representation, and the maintenance of data bits at memory locations in 
the memory system to thereby reconfigure or otherwise alter the processing unit's 
operation, as well as other processing of signals. The memory locations where data bits 
10 are maintained are physical locations that have particular electrical, magnetic, optical, or 
organic properties corresponding to the data bits. 

The data bits may also be maintained on a computer readable medium including 
magnetic disks, optical disks, organic disks, and any other volatile or non- volatile mass 
storage system readable by the processing unit. The computer readable medium 
1 5 includes cooperating or interconnected computer readable media, which exist 

exclusively on the processing system or is distributed among multiple interconnected 
processing systems that may be local or remote to the processing system. 

A preferred embodiment of the system is used in states which offer non- 
community medical rated. This requires the system to handle the complex nature of 
20 non-community medical underwriting. The system can be a rules-based, java-based 
application which codifies carrier eligibility rules. This embodiment automates the 
processes of on-line eligibility checking in order to cut down on enrollment and renewal 
errors which can potentially delay the enrollment process. 

A preferred embodiment includes instantaneous access to information within the 
25 CRM system and therefore, a dynamic on-line reporting system. 

FIGS. 2 A and 2B are schematic flowcharts 60, 100 illustrating the workflow 
processes, as tracked in a customer relationship management (CRM) subsystem, in 
accordance with a preferred embodiment of the present invention. The CRM process 
flow includes a sales process 62, a customer service process 64 and a finance process 
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66. In a preferred embodiment, the sales activity step 68 initiates the new sales activity. 
This initiation can occur from purchased lists or from an interaction on-line using a 
wide area network web product such as the Internet. The status of the sale process is 
tracked as shown in FIG. 2B. Once the status reaches 90%, a customer service activity 
5 74 is automatically created. When the sales activity reaches a status of 100% complete, 
an analysis activity 70 is created. In a preferred embodiment the analysis activity may 
not occur for a web-based inquiry. Further, a renewal activity 72 is automatically 
created when the analysis activity 70 reaches a status of 100% complete. The activities 
may be automatically created or in an alternate embodiment be manually created. 

10 The customer service activity 74 tracks the enrollment process and related 

subsystem activity. Once the enrollment status reaches a status of 90% complete, a 
finance activity 78 is created. The finance activity 78 tracks all of the steps necessary to 
activate an account for the billing subsystem. Once this activity has a status of 100%, 
the customer service activity is automatically updated to a status of 100% complete and 

15 the sales activity is automatically updated to a status of a 100% completed. 

In a preferred embodiment, the CRM system is based upon any CRM system, for 
example, the employee portal such as, but not limited to one provided by Onyx Software 
which is modified for use by the integrated system. The CRM system offers standard 
contact management functionality, such as tracking customer names and addresses, as 

20 well as contact names and addresses. Additionally, the CRM system tracks customer 
notes and customer "events". These events are broken into two major categories: tasks 
(which are items to be performed for the customer at a later date in time) and activities. 
In a preferred embodiment, the CRM system defines three types of activities: sales 
activities, service activities, and support activities. 

25 The integrated system utilizes all three of these activities. Sales activities are 

used by the sales department, service activities are used by the customer service and 
product support departments, and support activities are used by the finance and quality 
assurance departments. Sales, support and service activities give the system the ability 
to track minute details related to customer events. Each department defines their 
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activity types by way of a custom status, call results, priorities and activity source. An 
example of a sales activity is a new sales lead; an example of a service activity is a new 
enrollment. The CRM system has additional functionality, such as product tracking, 
quoting and mail merge, used in preferred embodiments of the present invention! 
5 The CRM process flow in preferred embodiments also includes maintenance 

processes. These maintenance provisions include, but are not limited to, processes to 
accommodate revisions (additions, deletions), terminations of policies and grievances. 

FIG. 3 illustrates a flowchart detailing the CRM process for the sales process in 
accordance with a preferred embodiment of the present invention. This process flows 
10 150 illustrates the interaction between the sales process steps and subsystems of the 

integrated insurance system 10. The sales CRM process 150 includes contact steps 152 
that occur either via telemarketing efforts or in an alternate preferred embodiment via 
on-line transactions using the Internet web product for the integrated insurance system 
10. For web access, the CRM subsystem 154 can generate a user name, a corresponding 
15 password and contact record. In a preferred embodiment the contact steps 152 can 
include a prequalification step, a data management step and an application step. 

The quoting steps 156 make use of the quoting subsystem 158 in order to 
generate a quote. In a preferred embodiment the quoting steps 156 include a written 
proposal process and an execution of the proposal process. The new business steps 160 
20 include the creation of a new customer service activity 162 when the sales status is set 
to 90% in accordance with a preferred embodiment of the system. 

FIG. 4 illustrates a flowchart detailing the CRM process for the customer service 
process in accordance with a preferred embodiment of the present invention. The 
customer service process 180 includes a step 182 for gathering information which 
25 serves as a first step. This step allows gathering of group or individual information via, 
but not limited to, telephone, web or electronic access from another vendor system, such 
as, for example, a payroll company. During this process all necessary forms, if 
applicable, are filled in and all required documents and signatures are gathered. A 
vendor subsystem 184 is in communication with the CRM process to enable step 182. 
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The process includes a subsequent step 186 of submitting information to a third 
party, such as a vendor. The information gathered from step 182 is transmitted to the 
vendor subsystem 192 for approval. The data gathered is also submitted to the 
enrollment subsystem 188 and the electronic "data interchange (EDI) subsystem 190. An 
5 event triggering subsystem that functions as a transaction processing subsystem may be 
used to determine which pieces of data to submit to the EDI subsystem. Data can be 
transmitted either via paper or hardcopy, facsimile or using the EDI exchange. The next 
step 194 is the completion of the enrollment process which includes the finance activity 
196 approving the account information and in a preferred embodiment activating the 

10 account for billing the client. The document management subsystem may be used to 
transfer paper-based data into an electronic format and store the information in a 
centralized location. 

FIG. 5 illustrates a flowchart detailing the CRM process for the finance process 
in accordance with a preferred embodiment of the present invention. The finance CRM 

15 process 220 includes the step of reviewing the account information 222. In a preferred 
embodiment the finance subsystem can make use of different subsystems to verify 
account information. Further, the billing information is updated per step 224. The 
billing subsystem 226 is in communication with the finance CRM process to enable the 
billing information update. The billing subsystem 226 is used to make any necessary . 

20 account changes and to fill-in required billing fields for billing purposes. 

The step 228 for activating the account for billing completes the finance 
subsystem's activity. Once the account is activated, the customer service activity 230 
has a status of 100% complete. 

FIG. 6 is a diagram illustrating the portal subsystems in accordance with a 

25 preferred embodiment of the present invention. The integrated insurance system 

application is composed of multiple portals which are used to access the system 10. The 
CRM system is used to manage the access rights, including user names, passwords and 
password expiration dates for all of the portal users. The portal subsystem 250 includes 
the employer portal 252 also known as the customer portal. This portal is used for 
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group insurance purposes. The employer portal ties together all of the employer 
functionality, including quoting, enrollment and, eventually, billing history into one 
central location. The customer is able to access the portal using one simple, secure log- 
in, located at, for example, https://secure.valuebenefits.com/login. In the system,* the 
5 customer username and passwords are setup via the CRM primary contact record. In the 
system, the username and password are created before the system account is created. 

Within the CRM system, the primary contact screen includes a username, 
password, password expiration date and user type. This username and password is used 
to validate the customer when they log into the system. The password expiration date 
10 permits the appropriate internal user to deactivate an account on a specific date. In a 
preferred embodiment, the user type field indicates the type of user that can access the 
portal, such as, for example, an employer, an employee, a carrier or a partner. In a 
preferred embodiment, the user type field indicates whether the user is an employer or 
an employee. 

15 The employer portal is the central location from which the employer can access, 

and control, his/her account. The employer portal consists of three main components in 
a preferred embodiment, for example, profiles (both company and employee profiles), 
quoting history and coverage policies. 

The profile section of the portal allows the employer to change his/her company 

20 address and contact information. The purpose of this section is to gather information 
which is used in all future quotes and enrollment processes. The employee profiles 
contain demographic and contact information for each employee, including their 
dependent(s). The employee list is used to populate census information for quotes and 
policy enrollment. The advantages of maintaining profile information include the 

25 availability of easy data entry. Instead of having to enter company information or 

employee information when creating quotes and enrollment, the profile information is 
available for easy data entry. 

The quoting section of the employer portal allows all new quotes to be saved 
automatically to the account. This allows an AE who calls up the account in the CRM 
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system to see all existing quotes for the customer. Furthermore, when the customer 
creates a new quote, their existing customer and employee information pre-populates the 
quote using the account profile information. 
. . . A preferred embodiment enables the ability to edit quotes for different insurance 
5 products. Any eligibility issues which arise if a customer changes company or 
employee profiles is manually tracked by the CSR and appropriate actions taken to 
resolve them. Another preferred embodiment implements a more sophisticated method 
of tracking potential eligibility issues which arise when profile information is changed 
by automating the tracking. 

10 In a preferred embodiment, when adding, editing or deleting enrollment 

information, an archive is made of all changes for tracking purposes. The archive tables 
store a copy of all of the information after it is changed by the user, as well as a flag 
which indicates the type of change: add (a), edit (e) or delete (d). The date and time of 
the change is also recorded along with user who made the revision. In a preferred 

15 embodiment, when adding, editing or deleting enrollment information, an event may be 
created which causes the event triggering subsystem to perform an action. These 
actions may include, but are not limited to, for example, notifying the employer or 
employee of a change, interacting with the EDI subsystem to generate an EDI file, 
generating an enrollment eligibility issue, contacting the carrier of an enrollment change 

20 or contacting the partner of an enrollment change. The event triggering tables contain 
rules. for setting up, for example, the events to be monitored, determining the action 
which should occur when a specific event is performed and determining when to 
perform the appropriate action. 

A preferred embodiment of the system contains the capabilities for terminating 

25 and changing coverage for employees. Employees can be terminated by accessing the 
employee list (under the employee profile) and pressing the link to delete an employee 
from the company. The employer is then presented with a list of all policies the 
employee participates in. The employer can terminate coverage for one or more of these 
policies. 



{J:\CLIENTS\ip\082238\3O00\3O0O-lOl\F0251479.DOC;!} 



082238.3000-101 

-26- 

To change the coverage for a specific employee, the employer is able to follow a 
link from the main page to "Change Employee Coverage." This link displays a list of 
coverage for each employee. The employer can then chose which employee and 
coverage they wish to change. 
5 It should be noted that each carrier has sophisticated eligibility rules for 

providing coverage to small groups. The preferred embodiment system determines if 
any of these rules are violated by terminating one or more employees. This ability may 
be left to the CSR who monitors all changes to the group. The system can incorporate 
carrier rules which dynamically track these types of changes and informs the customer if 
10 they are violating a carrier eligibility rule in a preferred embodiment. Thus, each time a 
customer changes the company, employee or dependent profile information, the 
information is backed up to an archive table. This archive table is used to keep track of 
adds, edits and deletes within the system, as well as to send change information to the 
carrier. 

15 Another preferred of the employer portal tracks employee discount cards. 

Discount cards are membership plans consisting of ancillary health care benefits that 
offer point of service discounts on products and services. The system provides these 
cards from a distributor to offer this service to the customers. On-line electronic 
payment capabilities are included in preferred embodiments. 

20 Another portal, the employee portal 254 is used by individuals, including 

employees of a group. The employee portal is the central location for an employee to 
log-in to manage his/her account. The need for an employee portal is driven by the 
system's expansion into individual lines of coverage, such as, for example, home 
owner's and automobile insurance. These types of policies are typically sold directly to 

25 an individual and not a small group. 

Thus, the employee portal allows the individual employee access to his/her 
company and private information. An example of an employee's company information 
is home address, telephone number. The employee's private information can include 
the names, date of births and social security numbers of his/her dependents. Other 
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private information includes potential automobile and home owner's insurance policies 
which the user has elected to receive through the employer, but ultimately passes 
through to the employee. The employee portal contains both company information, i.e. 
information related to their group, and individual information, such as an individual 
5 automobile insurance policy. Another embodiment provides employee's access to on- 
line provider directories. On-line provider directories help the customer select the best 
available plan which is offered with their existing physician, for example. 

The vendor portal 256 is an additional portal providing access to the vendors of 
disparate insurance products to system information such as, for example, reports on 

10 group counts, total premium sold, and commission tracking. The vendor portal may 
also be used by carriers to confirm, and eventually to change, for example, insurance 
product descriptions, regions where the products are offered, and rates, as well as to 
upload new product descriptions, regions and rates. The CRM system 258 is included 
in the portal subsystem which is used by the employees of the integrated insurance 

15 system, and as such is a portal available only for internal sources of the system 10. This 
CRM system 258 is different from the CRM subsystem described hereinbefore which 
can be accessed by groups, individuals or vendors. The partner portal is an additional 
portal providing access to various, non-carrier partners to system information such as, 
for example, reports on group counts, total premium sold, and commission tracking. 

20 The partner portal may also be used to exchange EDI files with the system, and to 
monitor partner groups which are being administered or marketed to by the system. 

FIG. 7 illustrates a schematic block diagram detailing the employer portal 
subsystem in accordance with a preferred embodiment of the present invention. The 
employer portal 252 accesses the integrated insurance system application 284 using the 

25 Internet 282. The application 284 includes multiple subsystems which in a preferred 
embodiment can be customized for the particular group or employer. These subsystems 
include the employer information management subsystem 286, an archiving subsystem 
288, the CRM subsystem 290, employee information management system 292, a 
quoting subsystem 294, a transaction logging subsystem 296, enrollment subsystem 298, 



{J:\CLIENTS\ip\082238\3000\3000-101\F0251479.DOC;!} 



082238.3000-101 

-28- 

customer billing subsystem 300, an underwriting and/or eligibility determining 
subsystem 302 and an EDI subsystem 304. In a preferred embodiment, the subsystems 
may communicate with other subsystems for data exchange or verification purposes. 
. Forexample, the quoting subsystem can call the vendor subsystem for particular 
5 information. 

The application 284 accesses and is in communication with the system database 
306a. . .n such as, for example, a CRM database or an application specific database. The 
employer portal is a central location where the customer can manage his/her account, 
including, for example, company name and address, employee names and addresses, 
1 0 quotes and lines of insurance coverage. 

FIG: 8 illustrates a schematic block diagram detailing the employee portal 
subsystem in accordance with a preferred embodiment of the present invention. Similar 
to the communication paths and access to subsystems, the employee or individual portal 
254 communicates with the integrated insurance system application 324 using the 
15 Internet 322. The subsystems such as, for example, employee information management 
subsystem 326, archiving subsystem 328, CRM subsystem 330, transaction logging 
subsystem 332, quoting subsystem 334, EDI subsystem 336, enrollment subsystem 338, 
customer billing subsystem 340 and underwriting/eligibility subsystem 342 can be 
customized for the particular employee portal. Further, in the preferred embodiments 
20 the subsystems may interface with other subsystems described with respect to other 
figures, such as the vendor subsystem. 

The databases 344a. . .n are included in storage devices for the storage of data 
and can be accessed when required for the employee portal process flow. The insurance 
coverage that the integrated insurance system 10 offers includes insurance for medical, 
25 property and casualty, automobile and homeowner's insurance. These products are 
directed towards individuals and groups. This individual service allows the system to 
grow beyond managing small business accounts. The employee portal allows the 
individual to view and modify private data, irrespective of their employer. The system 
coordinates employee changes with employer updates. 
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FIG. 9A illustrates a schematic block diagram detailing the vendor portal 
subsystem in accordance with a preferred embodiment of the present invention. The 
vendor portal 256 communicates with the application 364 using, for example, the 
Internet 362. The application subsystems and thus services include vendor information 
5 management 366, CRM subsystem 368, vendor billing subsystem 370, transaction 
logging subsystem 372, EDI subsystem 374 and archiving subsystem 376. The 
application 364 uses databases 378a. . .n to store and access information. 

FIG. 9B illustrates a schematic diagram detailing the partner portal subsystem in 
accordance with a preferred embodiment of the present invention. The partner portal 

10 262 accesses the integrated insurance system application 391 using a network such as, 
for example, the packet switched network, the Internet 382. The system application 391 
includes multiple subsystems which in a preferred embodiment can be customized for 
the particular group or employer. These subsystems include the partner information 
management subsystem 383, reporting subsystem 384, CRM subsystem 385, vendor 

15 billing subsystem 386, transaction logging subsystem 389, EDI subsystem 387 and 

archiving subsystem 388. In a preferred embodiment, the subsystems may communicate 
with other subsystems for data exchange or verification purposes. 

The system application 391 accesses and is in communication with the system 
database 390a. . .n such as, for example, a CRM database or an application specific 

20 database. The partner portal is a location where the partner can manage their account. 
FIG. 10 illustrates a flowchart detailing the process flow in the quoting 
subsystem in accordance with a preferred embodiment of the present invention. The 
quoting system 400 includes the step of selecting product choice(s) 402 which can 
include group product choices or individual product choices. The group product choices 

25 include: medical, dental, term life, short/long term disability, worker's compensation, 
and commercial automobile insurance. The individual product choices include: 
medical, dental, term life, short/long term disability, automobile*, home owners, and 
property and casualty insurance. The quoting system then includes the step of 
confirming and/or entering demographic information 404. This step 404 communicated 
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with the CRM subsystem 406, vendor subsystem 408, and the archiving subsystem 410. 
These subsystems may be called to automatically enter the employer/employee 
information. For group quoting, the employer may enter employee census information. 
The archiving subsystem tracks all changes to the system. The event triggering 
5 subsystem may be called at this point to trigger actions to other systems. For example, 
the EDI subsystem may be invoked to send off quoting data to applicable systems and/or 
users. The quoting subsystem then includes the determination step of customizing a 
quote 412. If a custom quote is required then the method 400 includes the step of 
selecting a product criteria 414. The type of product criteria is dictated by several 

10 factors, including, but not limited to, product choice and vendor choices. If, however, a 
custom quote is not required then a second determination is made in the step of 
ascertaining employer contribution 416. If the employer is contributing then the user is 
prompted to enter contribution amounts per step 418. The contribution amounts may 
only apply to some products and not all. If, however, the employer is not contributing 

15 then the process communicates with the underwriting/eligibility subsystem per step 422, 
and the vendor subsystem per step 424. The underwriting subsystem may be used for 
some product lines, but not all. In some instances the underwriting or eligibility 
checking can be carried out by a vendor subsystem. The final step includes quoting the 
results per step 420. 

20 In a preferred embodiment, the quoting system is a stand-alone system which is 

securely accessed via the system's home page on the Internet. In order to access the 
quoting system, the user logs. into the system using a valid account identifier (id) and 
password. The account id and password is distributed by an account administrator. The 
preferred embodiment quoting system can accommodate "anonymous" users. The 

25 concept of the anonymous user is based on a model in which a customer can create a 
quote using minimum information, i.e., no address or contact information, and save the 
quote. In a preferred embodiment, these quotes are not connected to an account. Unless 
the customer specifically tells the administrator which quote they have created, the 
administrator has no way of linking the quote to the customer's account. In an alternate 
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embodiment of the system of the present invention this constraint is removed and tightly 
couples an account to a quote. In an alternate embodiment, the quoting system may use 
the employee zip code to determine which medical plans are offered. The system can 
quote medical insurance and ancillary lines, such as, for example, but not limited to, 
5 term life, dental, long or short term disability. 

The quoting process is initiated by the customer logging into the system. Once 
the customer logs into the quoting system, they have the option of either creating a new 
quote or reviewing existing quotes. The review of existing quotes screen contains a list 
of quotes, including the quote name, date of the quote and the company name. Links 

10 exist to edit, preview or delete the quote. 

In a preferred embodiment, to create a new quote, the customer begins by 
entering their business zip code. The business zip code is used to determine if plans 
exist within the specified zip code. In a preferred embodiment, the customer can use a 
filter to determine which plans s/he wishes to view on the screen. The customer may 

1 5 filter the plans by selecting one or more carriers within the regional market, one or more 
plan types (such as, for example, without limitation, HMO, PPO, POS, etc), indicating a 
greater than, less than or equal to value for any of the market specific tiers (such as 
individual rate, individual + spouse rate, individual + child(ren) rate or family rate), 
indicating a greater than, less than or equal to value for the total monthly premium, 

20 indicating a greater than, less than or equal to value for a prescription value, which can 
consist of a prescription deductible, a generic prescription rate, a branded prescription 
rate or a prefer-branded prescription rate, selecting plans with or without prescriptions 
or selecting plans with or without open access. If plans do exist, then a list of carriers 
who represent the plans is displayed as well as a brief description of the process for 

25 creating a quote. The next screen gathers the customer's name, address, coverage start 
date and the employee count. The coverage start date, employee count and business zip 
codes are used to determine which plans and which rates to use to generate the quote. 
The customer does not have to re-enter his/her company information and employee 
information for each quote in a preferred embodiment of the integrated system. 
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In an alternate embodiment, once the company information is saved, the next 
screen asks the customer to enter their standard industry code (SIC) code or to lookup 
the SIC code via an application that guides the user through the process screens, for 
example, a wizard. This screen is optional and can be slapped if desired. The next 
5 screen collects the employer census information. The total number of employees 
displayed on the screen is determined from the customer information screen. For 
example, if the customer indicated they had five (5) employees, then this list would 
include five employees. The employee names are defaulted to "Employee n" where "n" 
represents a number 1 through 5. Additionally, the customer fills in the date of births, 
10 gender and type of coverage (either individual, individual plus spouse, individual plus 
child or children or family) for each employee. The census information is used to 
determine the exact rate to charge for each product. 

i The next screen asks the customer to select the amount they wish to contribute to 
their employee's medical plan coverage. The customer can contribute in three ways: 

15 flat fee, which is a specific dollar amount, percent of cost, which is a percentage of the 
cost for each plan, or the percent of lowest individual plan, which is a percentage of the 
lowest individual plan offered by the carrier within the determined market. These 
contributions can be made for each of the coverage levels, individual, individual plus 
spouse, individual plus child or children or family. 

20 The final screen displays all of the medical plans offered within the customer's 

business zip code. The plans are displayed in order of lowest price to most expensive. 
However, the customer can sort the list by any column by clicking on the column 
header. 

In a preferred embodiment, the customer can save the quote if they wish to view 
25 it again. To save a quote, the customer must enter a name for the quote, their electronic 
mail (e-mail) address and a password. In an alternate preferred embodiment quotes are 
automatically saved to a user's account. 

In another preferred embodiment, the quoting subsystem of the customer portal 
includes displaying ancillary insurance quotes. Instead of using the application wizard 
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approach to creating quotes, the quote has a more form-like appearance with the 
customer information at the top of the quote and employee coverage sections related to 
desired insurance products, such as medical, dental, life and short/long term disability. 
Each section of the quote has a button to change or edit the details. AH quotes are 
5 created by an AE using the custom screens described hereinafter. The company and 
employee demographic information is used to pre-populate the quote. 

In a preferred embodiment, the employer can request a quote on-line. The 
employer enters basic information and is directed to the website via an insurance broker. 
After entering the employer information and filling in the employee demographics, a 

10 quick quote is generated. The quick quote contains the various plans offered, including 
the low, medium and high options. The quick quote is an initial ball park quote that is 
based on basic information, such as employer zip code and alternatively based on the 
employee's age and gender. Its purpose is to demonstrate to the customer that the 
system can offer competitive prices along with employee choice of plans. In other r 

15 words, it is fundamentally a qualification tool. Someone who requests a quick quote 
can be reasonably assumed to be in the market. And getting a prospect to request a 
. quick quote is the first major milestone in the sales process. The inputs to a quick quote 
are: employer's zip code, the employer's name and address are optional, employer's 
county (automatically filled in based on the zip code), SIC code for the business (for 

20 most states is an optional parameter), total number of employees to be covered and 
employer's contribution level (also an optional parameter). For each employee the 
inputs include age (this depends on the State where the business is located), gender (this 
depends on the State where the business is located), and coverage type (Individual, 
Family, Individual + Spouse, or Individual + Child(ren)). The inputs are applied to a set 

25 of Base Rate Tables supplied by the carriers. In a preferred embodiment, at least three 
schedules of benefits from each carrier are provided based on feature set (and thus 
price), for example, low, mid, high. The carrier supplies the system with their rates for 
all of their plans. Included with the rates are all applicable qualifiers, such as age 
banding, gender, employee count banding and/or SIC codes. Furthermore, the carrier 

\ 

{J:\CLIENTS\ip\082238\3000\3000-101\F0251479.DOC;!} 



082238.3000-101 

-34- 

determines which "regions" each of the plans are offered in. A region is defined as a set 
of zip codes. A region can be as simple as one or more counties or can a custom- 
defined selection of zip codes. In either embodiment, each region must contain a unique 

set of zip codes within the state, in other words, a single zip code cannot appear in more 

5 than one region. A quick quote can be formatted using HTML. 

FIG. 1 1 A illustrates a flowchart detailing the process flow in the enrollment 
subsystem in accordance with a preferred embodiment of the present invention. The 
enrollment subsystem 460 includes the step of confirming and/or entering demographic 
information 462. This information is communicated to the CRM subsystem per step 
10 464, the vendor subsystem per step 466, and the archiving subsystem in step 468. These 
subsystems can be called to automatically enter the employer/employee information. 
For group quoting the employer can enter employee census information or use the CRM 
subsystem to setup username and passwords for employees to enter the system 
themselves. The archiving subsystem tracks all changes to the system. In an alternate 
1 5 embodiment, an existing customer quote may be used as the default data for an 

enrollment. In this embodiment, the company demographic information, contribution 
amounts, employee census and selected plans are used as the basis for the enrollment 
sequence of instructions or wizard. 

The next step in the process includes selecting product choice(s) per step 470. 
20 The group product choices include: medical, dental, term life, short/long term disability, 
worker's compensation and commercial automobile insurance. Further, the individual 
product choices include: medical, dental, term life, short/long term disability, 
automobile, home owners, and property and casualty insurance.' 

The next step in the process 460 includes the step of selecting available plans per 
25 step 472. Since the quote typically offers the clients, for example, the 
employer/employee, one or more choices, some products can require the 
employer/employee to select one or more plans from the available options. The next 
step in the process includes the determination whether there is an employer contribution 
per step 474. If yes then the user is prompted to enter contribution amounts per step 
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476. The contribution amounts may only apply to some products and not all. If the 
employer is not contributing, then the next step includes confirming the information 
478. The underwriting/eligibility subsystem per step 480, and, the vendor subsystem 
482 provide inputs to step 478. The underwriting subsystem can be used for some 
5 product lines, but not all. In some instances the underwriting or eligibility checking 
may be carried out by a vendor subsystem. The next step includes checking for errors in 
step 484. If errors are found by the underwriting/eligibility subsystem, or reported by 
the vendor subsystem, the user may be asked to return to any of the previous steps to 
correct the problem. However if no errors are found then the process proceeds to the 

10 step of submitting information per step 486. The vendor subsystem 488, and the EDI 
subsystem 490 provide inputs to step 486. Information can be transmitted via mail, 
facsimile, EDI or vendor web services in the vendor subsystem. 

The enrollment system is a simple interface for the customer in a preferred 
embodiment. The enrollment system centers around a workflow application which 

15 walks the customer through the enrollment process. The enrollment system 
accommodates medical enrollment, life insurance enrollment, dental insurance, 
automobile and other insurance enrollments without limitation. The enrollment process 
is started by the customer service representative (CSR) in the CRM system. The 
process continues with the customer logging into the system, filling in the required 

20 information, and then completing the enrollment by pressing the "Complete" button. 
The CSR finalizes the enrollment after reviewing the information for accuracy and 
eligibility and activates the account. The customer's role of filling in the enrollment 
details is described hereinafter. 

The customer starts the enrollment process by logging into the system. The log 

25 in page is located, for example, at https://secure.valuebenefits.com/ and is described 
with respect to screens that a user interfaces with hereinafter. After logging in, the 
customer has access to a menu, for example, Complete New Enrollment. This option 
brings the customer to the new enrollment workflow application, for example, a wizard. 
The workflow wizard application is setup to handle the enrollment of any insurance 
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product. The application walks the user through all of the steps necessary to complete 
the enrollment process, including, but not limited to, employer demographics screen, 
employer information screen, employer contributions screen, employee information 
screen, employee plan list screen; employee plan choose screen, and the insurance forms 
5 screen. 

In a preferred embodiment, the first screen in the enrollment application is the 
employer demographics screen. This screen asks the customer to enter their company 
contact name and address. All required fields are indicated with a red asterisk. The 
customer cannot save the information unless all required information is entered. This is 

1 0 true for all of the remaining screens. 

The next screen, the employer information screen, gathers the following 
information: tax identification number (TIN), business start date, number of employees 
in the company, the medical policy effective start date, the employer's SIC code and an 
employee probation period. The employer information screen is unique in that data 

1 5 input elements at the bottom of the screen are dynamically loaded for each carrier. This 
allows the system 10 to setup custom input fields for each vendor or carrier and to 
collect company information for the carrier. This custom information can then be used 
to populate carrier group enrollment forms. 

The next screen, the employer contributions screen, is similar to the employer 

20 contributions screen in the quoting system. Continuing on, the employee information : 
screen lists all of the employees for the company. This list contains the employee's 
name, social security number (SSN) and date of birth. An add button at the top of the 
* list functions as the user interface and allows the customer to setup new employees, 
while a delete button next to the employee's name allows the customer to delete the 

25 specified employee. Clicking on the employee's name opens a new window, the 
employee information window. This screen contains detailed information on the 
employee, including, but not limited to, for example, his/her name, address, date of 
birth, social security number (SSN) and other specific employee information. As with 
the employer information screen, this screen is unique in that data input elements at the 
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bottom of the screen are dynamically loaded for each carrier. This allows the system 10 
to setup custom input fields for each carrier and to collect employee-level information 
for the carrier. This custom information can then be used to populate carrier member 
enrollment forms. 

5 The employee information screen contains a link to a list of dependents. Similar 

to the employee list, the system provides a lists of all dependents associated with this 
employee. The same steps can be followed to add, edit or delete a dependent. 

The next screen in the enrollment workflow application is the employee plan 
list. This list is meant to be a print out for the employer. It contains all of the available 
10 plans for each employee, including the rates for individual, individual plus spouse, 
individual plus child or children and family. The employer can print out this list for 
each employee, hand it to the employee and ask them to select their plan and coverage 
level. 

Once the employer gathers the list from the employee, the next screen allows the 
15 employer to input which employee selected which plan at which coverage level. The 
employee plan chooser screen contains a list of all employees in the company and 
selection fields for the plan names and coverage levels. After saving this information, 
the customer can proceed to the next screen. By matching the employee to specific 
carrier plans, the system can accurately determine which enrollment forms need to be 
20 filled-in in order to complete enrollment. 

The final screen in the enrollment application displays a list of the employees 
with the corresponding forms which need to be filled in to complete the enrollment 
process. The system automatically matches up which enrollment forms are necessary 
for the selected plan. 

25 In a preferred embodiment the system does not pre-populate the enrollment 

forms with group or employee information. Another preferred embodiment includes 
functionality to pre-populate the basic enrollment fields for each of the carrier forms. 
The basic enrollment fields are defined as the common fields shared by each carrier, 
including employee and dependent name, address, date of birth, SSN and gender. Pre- 
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populating the enrollment forms is a significant time saver for the customer and/or CSR 
who fills-in the forms. 

Once the medical or any other enrollment information has been gathered, the 
' customer can press the "Complete" button on the workflow page of enrollment 
5 application. Pressing this button initiates two steps including the step of checking all 
information to ensure no required fields are missing and if all required information has 
been completed then the policy status is set to "Pending." A CSR who monitors the 
account then knows to complete the enrollment process. 

In another preferred embodiment, the coverages more closely resembles the 
10 quoting format. In a different preferred embodiment the coverage information is 

divided among the enrollment wizard application pages. This can make it difficult to 
get a quick overview of the policy coverage. The preferred embodiment starts with a 
list of active policies. This list contains an item for each active policy, including the 
policy name, the effective coverage dates, the policy status and a button to review the 
15 coverage details. The coverage detail page displays the company information at the top 
of the page, followed by a section on the employer's contributions. The employer's 
contribution section is divided into each elected coverage type, such as medical 
contributions, dental contributions, etc. The next section displays which employees 
elected which line of coverage. The list includes the employee names, plan numbers 
20 and rates for the various coverage sections. 

The enrollment process is customizable in that each of the required carrier data 
elements can be setup in the system and gathered through the enrollment process. The 
enrollment process is dynamic in that which ever carrier is selected during the 
enrollment process, the enrollment screens dynamically change to accommodate the 
25 individual carrier requirements. For example, if a customer selects Aetna Connecticut, 
then the enrollment process includes all of the customized data elements for Aetna. 

When dealing with renewals, the system take a proactive stance. The system 
prompts a contact with the client 30-45 days in advance of their renewal date. The goal 
is to make the renewal process as simple as possible. If the client does not respond by 
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canceling their policy, the assumption is that they will continue using the updated rates. 
Each customer has user preferences defined on how they would like to be contacted for 
renewal, for example, electronic mail, fax, letter. 

FIG. TIB illustrates a diagram of the carrier management subsystem (CMS) 495 
5 in accordance with a preferred embodiment of the present invention and the 

functionality provided by the CMS. A user can select a state per step 496, and select a 
line of business (for example, medical, dental) per step 498 using the CMS subsystem. 
A user can view carriers per step 500 and add, edit or delete the carrier per step 508. 
Similarly, the CMS subsystem allows a user to view carrier plans per step 502, to add, 

10 edit, delete plans per step 510, view carrier regions per step 503 and add, edit or delete 
regions per step 512. Carrier benefit summaries can be viewed per step 505, and these 
summaries can be added, edited or deleted per step 513. The CMS subsystem also 
provides for viewing carrier provided directories per step 506 and for adding, editing or 
deleting these provider directories 514. 

15 . The CRM subsystem 5 1 6, the vendor subsystem 517, the reporting subsystem 

518 and the EDI subsystem 519 as a minimum can be called by the CMS subsystem to 
automatically enter the carrier information. The vendor portal may be called by the 
vendor to review any new plans, rates or regions which have been set up via the CMS 
subsystem in accordance with a preferred embodiment of the present invention. The 

20 reporting subsystem can be called to view new plans, rates or regions. The EDI 
subsystem can be called to set up new EDI files to the respective vendor(s). 

FIG. 12 illustrates a flowchart detailing the process flow for the billing 
subsystem in accordance with a preferred embodiment of the present invention. The 
billing system builds a custom invoicing system which performs basic billing functions, 

25 including tracking customer invoices, customer payments and carrier remittances. 

These transactions are recorded in a general ledger which produce a basic balance sheet 
and profit and loss statement. The basic functionality is to generate basic invoices based 
on enrolled individuals, post the monthly invoices to a general ledger account, calculate 
the carrier's remittance at the time of posting and to post the remittance amounts to the 
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carrier's holding account, receive payments against the posted invoices, upon receiving 
payment, move the carrier's holding to a carrier's liability account, remit the carrier's 
liability, generate a basic chart of accounts, and generate a basic balance sheet and 
profit/loss statement based on the transactions listed hereinbefore. 
5 A preferred embodiment of the present invention includes a custom billing 

application to accommodate the unique needs of any business. The billing system 
includes a chart of accounts, G/L module and basic Account Receivable (AR) module 
for tracking customer invoices. The embodiment of the system tracks customer invoices 
and payments, carrier remittances and basic account adjustments. A Chart of Account is 

10 used to keep track of carrier balances. A Profit and Loss (P/L) and Balance Sheet (B/S) 
are used to keep track of all transactions in the system. 

The general process for enrolling a new company in a preferred embodiment 
includes, the customer service representative creating a new account. The CSR receives 
the employer's name, address and primary contact. The CSR receives the name of the 

15 carrier who the employer wishes to enroll with and the schedule which is used by this 
carrier. The customer service representative then creates a new policy for the account, 
for example, type = "medical'' and creates a user name and password for the employer. 
The customer service representative selects the carrier for the policy, and the employer 
logs on to the system. The employer enters his/her company information, SIC Code, 

20 enrollment terms, employer's contribution (a.k.a. "Matching") levels for each coverage 
type. The employer enters the employee's name and address and prints out a list of all 
of the plans available for each employee. The list is given to the employee for him/her 
to select a plan and a coverage level. The employer gathers the list and enters into the 
system which plans the employee selected. The employer prints out the enrollment 

25 forms for his/her employees and distributes them, the employer reviews, submits the 
group employee enrollment information. 

The following table is a list of the basic enrollment reports for reporting on and 
tracking the customer service issues and enrollment. These forms can be viewed by 
typing the report name. 
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Table2 





iReponw I 


ll^SripS^nB 


CRM 


Customer Service Activity Summary 


Summary of CRM activities, such as New 
Enrollments, BORs, grievances, etc. 


CRM- 


Customer Service Activity Details 


Detailed report which lists each customer 
by Customer Service activity. The reports 
displays the current status and call result. 
NOTE: This report has three variations: 

1 . ) All Items in the customer activity 

list 

2. ) Only open items in the customer 

activity list 

3. ) Only closed (inactive) items in 

the customer activity list. 






CRM 


CRM carrier Enrollment Summary 


This report displays a summary of all the 
enrolled groups, including the total 
number of enrollees and the average 
enrollee size. 


CRM 


CRM carrier Enrollment Details 


This report displays the details of all the 
enrolled groups sorted by carrier, 
including the group address, policy and 
enrolled type. 




Pre-Enrollment Summary 


Displays all of the accounts in the system 
which are not currently active. The 
policy status is also included on the 
report. 




Enrolled Group Summary 


This reports give a summary of all of the 
active groups enrolled in the system. 




Enrolled Employee Summary 


This reports give a summary of all of the 
active employees enrolled in the system. 




Enrollment Change Report 


Report which is sent to the employer 
indicating any changes to enrollment, 
including Company, Employees and/or 
dependents. 




Enrollment Change Tracking 


Summary report which lists how many 
adds/edits/deletes occurred within 



The general processing on renewing an existing plan includes approximately 30- 
45 days before renewal; the client is sent a reminder of renewal. The reminder includes 
the new renewal rates (based on their current enrollment), and information on all other 
policies plans with rates and contract levels (low/med/high). A copy of the contract can 
5 be sent in a preferred embodiment. 



{J :\CLIENTS\ip\08223 8\3000\3000- 1 0 1 \F025 1 479. DOC; 1 } 



082238.3000-101 



-42- 

The general steps for changing the coverage type includes the employer selecting 
the employee whose coverage has changed, and the employer selecting the new 
coverage type. For example, the employee may change from an individual policy to a 
family policy. The reason for the change is* selected and the effective date of the change 
5 is entered. The Policy Holder table (and/or Monthly Billing Profile table) is updated 
with the new information. When the enrollment information is changed, the following 
rules are likely to affect billing: changing the carrier plan, this can affect the cost, 
changing the contract type (family versus individual), adding or removing employees 
can affect the billing, if their plan is based on employee counts and adding or removing 
10 dependents do not affect billing. 

Some examples of typical enrollment changes are listed below, as are the items 
that appear on the client's bill. Changes in enrollment affect monthly billing. 



Table 3 



Person JD^~ 


Coverage 
Type 


in Status 


; Effective 

.• ; -Date -.. ; : 


Month : : 


John Smith 


Family 


Add 


01/01/01 


JAN 01 


Mary Jones 


Individual 


Add 


01/01/01 


JAN 01 


John Smith 


Individual 


Change 


01/01/01 


FEB 01 


Mary Jones 


Individual 






FEB 01 


John Smith 


Individual 






MAR 01 


Mary Jones 


Individual 


Delete 


02/01/01 


MAR 01 


John Smith 


Individual 






APR 01 



In a preferred embodiment, in order to change the coverage type for an employee 
15 the following are required: qualifying event code (provided by individual carriers), 

qualifying event reason (same as above), and effective date (note the effective date must 
equal the qualifying event date). 

The following are examples of coverage type changes. In a first example, Bob 
has been married for two months. He goes to employer and asks to have his wife added 
20 to his policy. Because the carrier has a 30 day retroactive rule, he is hot be able to add 
her until the next open enrollment. In example two, before the open enrollment, Bob's 
wife gives birth to a new baby boy. Because the birth of his son qualifies as a 
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Qualifying event, he is able to change his coverage type. At this time, he can add his 
wife and his child to the policy effective as of the child's birth. In example three, Bob 
has never had coverage from his employer since he has always been covered under his 
wife's policy. However, his wife looses her job. Bob can now ask his employer to 
5 change his coverage type. He and his wife (and family if present) can be added to plan. 
The effective coverage would begin at the point when his wife's date of coverage loss. 
In example four, the company is growing leaps and bounds and adds 10 new employees 
within the year. The employer's base rate of coverage would not change. However at 
renewal, the system calculates a new base rate for the company based on the current 
10 employee count. In scenario five, Bob's employer knows that one of his employee's 
will be terminating in two months. He goes into the system and enters a future end date. 
The system continues to bill Bob for his employee's coverage until the future month is 
reached. 

Some of the business rules that apply for enrollment changes include qualifying 
15 event codes are only applied to adds, not deletes, check if the change date falls within 
the carriers accepted retroactive period, adjust billing if change falls within previous 
billing period, no billing adjustments need to be made for families who add or delete 
dependents unless the coverage type changes, and if a change does not fall within the 
qualifying event date (or reason) then the employee must wait until the next open 
20 enrollment period. This is typically once per year and falls on the Employer's renewal 
date. Note births and deaths are typical qualifying events. Each time a new invoice line 
item is created, the policy rate needs to be looked up, since the carrier rates can change. 
In order to terminate coverage in accordance with a preferred embodiment, an employee 
requires a termination code (provided by individual carriers), termination reason, and 
25 termination date. The applicable business rules include checking if the termination date 
falls within the carriers, accepted retroactive period. 

The billing subsystem process flow 520 may be called to automatically enter the 
employer/employee information. The billing subsystem 522 includes a client billing 
subsystem 524, a vendor billing subsystem per step 526 and a sales commission 
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subsystem 546. The client billing subsystem 524 includes the invoicing subsystem 548 
which is responsible for generating customer charges/credits based on customer policy 
details. These policy details are kept in a table described hereinafter called 
ENR_PolicyHistory. The client billing subsystem 524 also includes the general ledger 
5 posting subsystem 550. This subsystem 550 includes the process of copying all invoices 
to the general ledger (G/L). The G/L is associated with the table BIL_GenLedger 
described hereinafter. The client billing subsystem 524 further includes the customer 
payment subsystem 552. This subsystem 552 is responsible for tracking those invoices 
that are paid in full or partially paid by the customer. The client billing subsystem also 

10 contains the customer statement subsystem. Customer statements are generated off of 
existing charges, credits and payments found in the G/L, and are the basis for customer 
bills. Customer statements may be generated as frequently as desired as long as any 
new activity is found in the G/L. Thus, a new statement can be generated for a customer 
as long as there are new charges, credits or payments that have not been previously 

15 accounted for on another statement. In a preferred embodiment, a system credit liability 
account is used to track customer credits, which can result from overpayment of 
invoices, or sending in checks before statements are submitted to a customer. The client 
billing subsystem is complemented by the overdue account subsystem. This subsystem 
generates overdue notices for customer statements in the form of a first notice, a second 

20 notice and finally a termination notice. 

FIG. 13A illustrates the flowchart detailing the process flow for the invoicing 
subsystem 548 included in the client billing subsystem which is included in a billing 
subsystem in accordance with the present invention. For a client invoicing process in 
accordance to a preferred embodiment, the process includes the step of retrieving active 

25 policies for each account per step 528. Then a determination is made to check if the 
account has already been invoiced per step 530. This can include the table 
ENR_PolicyHistory being checked to see if there are any new charges or credits that 
have not yet been invoiced for the current invoice month. A new invoice is generated 
for each policy that has new charges or credits. If yes, then the account is skipped per 
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step 532. If not then the next step in the process includes retrieving a billing profile per 
step 534. The process next includes inserting invoice details per step 536. An invoice 
header is inserted per step 540 and an invoice number is generated per step 542. 
Invoices are posted to the G/L posting subsystem per step 550. In a preferred 
5 embodiment, invoices may be generated as frequently as desired as long as any new 
charges/credits are found in the ENR_PolicyHistory table. 

FIG. 13B illustrates a flowchart detailing the process flow for posting invoices 
which is included in the billing subsystem in accordance with a preferred embodiment 
of the present invention. The invoice posting subsystem 604 includes the step 606 of 

10 loading unposted invoices. Per step 608 all unpaid but posted invoice headers are 

loaded. It is then determined per step 610 what policy type forms the subject matter of 
the invoice. If the policy is a standard policy then per step 612 invoice detail amount is 
moved to accounts receivable. Further, invoice detail amount is moved to carrier 
holding account per step 614. The process then culminates in step 622 where the 

15 invoice detail is marked as posted. 

If however, the policy is a non-standard policy then it is determined if the policy 
has an associated commission in step 616. If there is no commission then the process 
concludes at step 622 by marking the invoice detail as posted. In a preferred 
embodiment, invoices for non-standard policies are immediately marked as paid as no. 

20 customer payment is expected. If a commission is associated with the policy then, the 
commission is calculated based on a carrier schedule per step 618. A carrier accounts 
receivable (A/R) matter is then created per step 620, followed by the culmination of the 
process in step 622. 

FIGS. 14A and 14B illustrate a flowchart detailing the process flow for the 

25 billing subsystem, in particular the client payment process in accordance with a 

preferred embodiment of the present invention. The billing subsystem includes a client 
payment method 560 which includes the step of creating a payment header per step 562. 
The process then includes generating a system payment identifier (id) per step 564 and 
loading all unpaid (posted) invoice headers per step 566. The next step includes the 
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determination whether to apply payment per step 568. If credit needs to be used then 
per step 570 a check for credit is conducted. If credit exists then debit systems credit 
liability per step 572. If, however, a payment is provided then per step 574 a payment 
detail such as an invoice is created. Then per step 576 a general ledger (G/L) entay in 
5 the invoice is created. The general ledger is then updated for the amount of payment 
applied to the invoice. This activity includes the calculation of vendor remittance 
amounts and commission calculations. This activity drives the vendor billing and 
commission payment subsystems. The process then includes updating the invoice 
header balance per step 578. The determination is then made if the invoice is balanced 

10 per step 580. If the balance equals zero then the invoice status which equals paid in full 
is updated per step 582. Per step 585, the general ledger is then updated and the process 
progresses to step 586 described hereinbelow. In a preferred embodiment step 585 is 
not required. If, however, the balance is not zero, then the invoice status which equals 
partial pay is updated per step 584. It is then determined if the payment is balanced per 

15 step 586. If credit remains then a system credit liability is created per step 588. If, 
however, no credit remains then per step 590, the account balance is updated. 

FIG. 15A illustrates a flowchart detailing the process flow for the billing 
subsystem, in particular the vendor billing subsystem 526 in accordance with a preferred 
embodiment of the present invention. The vendor billing subsystem 526 is one 

20 component of the billing subsystem 522 and includes a carrier remittance subsystem 600 
and a carrier commission payment subsystem 602. The carrier remittance subsystem 
600 is responsible for tracking all partially paid customer invoices and remitting the 
correct premium amount back to the carrier. The amount can either be the gross 
payment or a net payment based on the payment schedule established between the 

25 system and the carrier. The system allows the user to either remit over or under the 
amount specified by the system's calculation. This is done so that discrepancies 
between the system and vendor expectations can be managed. The invoice system may 
react more quickly to charges and credits than the vendor's system do, so this allows 
timing issues to be balanced out. The information pertaining to this subsystem 600 is 
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stored using tables such as CAR_RemittanceHeader, CAR_RemittanceDetails that are 
described with respect to FIGS. 16A-1, 16A-2, 16B-1, 16B-2, 17A-1, 17A-2, 17B-1 and 
17B-2. The carrier commission payment subsystem is responsible for tracking 
commissions owed to the system by the carrier for any premium collected from the 
5 customer directly. In a preferred embodiment, the commission amount is based on the 
payment schedule established between the system and the carrier. The system allows 
* the user to collect commission over or under the amount specified by the system's 
calculation. This is done so that discrepancies between the system and vendor 
expectations can be managed. The invoice system may react more quickly to charges 

10 and credits than the vendor's system do, so this allows timing issues to be balanced out. 
The data for this subsystem is stored in tables such as, but not limited to, 
BEL_CarrierPaymentHeader and BIL_CarrierPaymentDetails, described with respect to 
FIGS. 16A-1, 16A-2, 16B-1, 16B-2, 17A-1, 17A-2, 17B-1 and 17B-2. 

The structure for the commission calculation in the system is flexible to 

1 5 accommodate multi-tiered commission based billing and tracking. The method of 
calculating the premium is based on factors for both the carrier chosen and the Agent 
who brokers the deal. Each carrier and Agent has associated business rules for 
determining their commission on the sale. The billing system provides for billing the 
premium to the employer group, billing a service fee to the employer group on top of the 

20 premium bill, billing for late fees (or finance charges), generating payments to the 

carriers which displays the aggregate totals, generating itemized submission statements 
to the carriers, and generating itemized payment statements to the agent. 

The remittance amount for the carrier is typically either percentage based or flat 
fee per employee per month (FFEM), the system handles flat rate adjustments. Each 

25 carrier has a base rate (usually percentage based). This base rate is set for each of the 
markets the carrier participates in. Note that each carrier is able to setup their own 
markets. This is done by zip code. Each carrier can have adjustments to their base rates 
based on premium volumes. The adjustment rate may be based on the specific carrier 
markets as well. Furthermore, the adjustment rates may be affected by the date of the 
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sale (either per month, per quarter or per year). Normally the volume adjustments are 
based on carrier markets, however, override adjustments based on total carrier volumes 
can be made. For example, when a volume across all of a carrier's market reaches a 
value, adjustments can be made. 
5 Each carrier can have adjustments to their base rates based on premium volumes 

or employee count for specific employer groups. For example, a carrier can negotiate a 
deal on commission rates when dealing with a large employer group. When a 
commission rate changes (either due to volume or employer group parameters), the 
changes can be retroactive to the start of the year. For multi-region employer groups, a 
1 0 single bill can be generated to the employer group listing each member by group and by 
market. When making payments to carriers, a sole depository for each carrier market is 
identified. 

In a preferred embodiment agent commission portion (a.k.a. sales person, 
individual or agency brokers) are considered when calculating commissions on each 

15 sale. In the preferred embodiment of the present system, agents can be either system 
sales people, individual external brokers or external broker agencies. In order to unify 
the billing process, system sales people are considered a "type" of agent. A manager 
working as an insurance broker for the system may be an agent and she/he may have 
individual brokers ("sales people") working for her/him. Each agent may have a 

20 different commission rate per carrier. Agents and individual brokers may have volume 
steps on premiums. These steps are percentage based, but may be flat fee based as well. 
Agencies require one check with itemized commissions for individual brokers. 

When a prospect accepts a final quote and decides to sign up, what they have 
accepted is a quote based on their specific employees. The quote is provided in two 

25 ways including list-billed (actual per individual) rates and composite rates. A list bill is 
one in which each employee is billed at the rate specified by the carrier's plan. A 
composite bill takes the average of all carrier's plan rates for each tier level. The 
following table is a composite rate sample (individual tier). 
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Table 4 





fCarrielil 








Person 1 


$200 


1 


$200 




Person 2 


$300 


1 


$500 




Person 3 


$400 




-$800 


1 


Composite Rate 


$300/P 


2 


$500/P 


1 


Composite Bill Amount 


$600 




$500 





Notice that the composite rate is based on the total number of participants. For example 
for carrier A, the composite rate is calculated as: 

composite rate (carrier A) = ((1 person * $200) + (1 person * $300) + (1 person * 
5 $400))/3 People 

composite rate (carrier A) = $300 per person 

Note: If there were people who chose family over Individual, their total cannot be used 
to calculate this composite rate. The composite rate is for a specific tier level The 
composite rate is based on a hypothetical and the algorithm includes identifying the total 

10 number of different tier levels actually selected, for each tier level, identifying the total 
number of different plans selected, for each tier level, identifying which employees 
selected that tier level, for each tier level and for each selected plan within that tier 
level, and calculating the average actually cost as if all employees within that tier level 
had selected the plan. The employer specifies their contribution policy. There are 

15 options for this, for example, the business owner agrees to pay 100% of the composite 
individual rate and 0% beyond this (i.e., no contribution to the family rate), or the 
business owner agrees to pay 50% of the composite rate for any plan. The type of group 
options (tier levels) offered varies by state. For example, Massachusetts uses two 
groups: individual and family. Other states offer more groups, for example, individual, 

20 employee/spouse, employee/one dependent, and employee/two dependent. The 
employer gets billed on the composite rate based on the actual plans chosen. 

There is a possibility that the composite rate does not add up to the individuals. 
In a preferred embodiment a monthly billing process occurs in order to generate 
invoices for the client. The process is based on the client's monthly billing profile 
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, (MB?) table. This table contains all of the "line items" which appear on the bill. The 
monthly configuration table consists of the following types of line items, for example, 
policy items (i.e. carrier plans). For example, each employee's policy is a policy line 
item (Item Type = 1). Another line item includes carrier items (items which are passed 
5 on to the carrier). A carrier may receive a special charge which is charged to the 
employer (Item Type = 2). Agency items (items which are passed on to an external 
broker agency) address agency having an additional charge, such as an administration 
fee, which is charged to the employer (Item Type = 3). System items (items which are 
passed on to the company) attach additional charges, such as finance or administration 

10 charges, to an invoice (Item Type = 4). The monthly billing is based on the current 
enrollment for each account. Enrollment changes which affect the client invoicing 
appear in the monthly profile table. At the beginning of each month, the monthly 
invoicing process views these changes and updates the invoicing accordingly. An 
invoice number generator generates the invoice number which is built using the 

1 5 following components: Invoice Num = Site ID + MMYY + "-" + Monthly Counter. 
The counter is reset each month to zero. To maintain the monthly invoice number, a 
table is created which holds the customer site id, last invoice date and the invoice 
counter. 

An example of how enrollment changes affect monthly billing is described in 
20 accordance with the present invention. In the sample configuration table below, Joe's 
Garage has 5 employees: Patrick Houle, Terry Isaks, Mark Petins, Paul Peters and Bob 
Jones. Joe's Garage was last invoiced in March 2001. During the month of March, 
Patrick decided to change his coverage from individual to family, effective February 
2001; Mark decided to terminate employment as of March 31, 2001; Paul decided to 
25 switch from Aetna to Cigna' s plan; and Bob decided that starting in May 2001 he would 
like to change from Individual to Family coverage. The billing configuration table 
below represents Joe's Garage's billing situation for April 2001. 
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Table 5 



Plan 






Date 


Fnd 
Date 


T ast 

Ijuol . 

Invoiced 


Remarks 


AET01 


Patrick Houle 


Individual 


09/98 


02/01 


03/01 


Change 


AET01 


Patrick Houle 


Family 


02/01 






AET01 


Terry Isaks 


Family 


01/98 




03/01 




AET01 


Mark Petins 


Family 


04/98 


04/01 


03/01 


Terminate 


AET01 


Paul Peters 


Individual 


04/98 


02/01 


03/01 


Change 


CIG01 


Paul Peters 


Individual 


02/01 






CIG01 


Bob Jones 


Individual 


05/98 


05/01 


03/01 


Future 
Change 


CIG01 


Bob Jones 


Family 


05/01 







the resulting invoice is: 



Table 6 



Plan . / 


Policy 
■Holder; - 


Coverage. 


Description V • " r ^ 


V;jRate; : - • 


AET01 


Patrick 
Houle 


Individual 


Reversed Medical Coverage . 
for Feb 2001 


($235) 


AET01 


Patrick 
Houle 


Family 


Medical Coverage for Feb 
2001 


$435 


AET01 


Patrick 
Houle 


Individual 


Reversed Medical Coverage 
for Mar 2001 


($235) 


AET01 


Patrick 
Houle 


Family 


Medical Coverage for Mar 
2001 


$435 


AET01 


Patrick 
Houle 


Family 


Medical Coverage for Apr 
2001 


$435 


AET01 


Terry 
Isaks 


Family 


Medical Coverage for Apr 
2001 


$435 


AET01 


Paul 
Peters 


Individual 


Reversed Medical Coverage 
for Feb 2001 


($256) 


CIG01 


Paul 
Peters 


Individual 


Medical Coverage for Feb 
2001 


$242 


AET01 


Paul 
Peters 


Individual 


Reversed Medical Coverage 
for Mar 2001 


($256) 


CIG01 


Paul 
Peters 


Individual 


Medical Coverage for Mar 
2001 


$242 


CIG01 


Paul 
Peters 


Individual 


Medical Coverage for Apr 
2001 


$242 


CIG01 


Bob 
Jones 


Individual 


Medical Coverage for Apr 
2001 


$242 
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Note that Mark does not show up on the invoice because he was terminated during the 
last month that was invoiced. 



Table 7 



.Plan \ 


Policy Holder 


Coverage 


Start 
Date 


End 
Date 


Last 
Invoiced 


.Remarks , 


AET01 


Patrick Houle 


Family 


02/01 




04/01 




AET01 


Terry Isaks 


Family 


04/98 




04/01 




CIG01 


Paul Peters 


Individual 


02/01 




04/01 




CIG01 


Bob Jones 


Family 


05/01 




04/01 





The resulting invoice is: 
5 Table 8 



Plan 


Policy 
Holder 


Coverage 


Description . V 


; ; Rate 


AET01 


Patrick 
Houle 


Family 


Medical Coverage for May 
2001 


$435 


AET01 


Terry Isaks 


Family 


Medical Coverage for May 
2001 


$435 


CIG01 


Paul Peters 


Individual 


Medical Coverage for May 
2001 


$234 


CIG01 


Bob Jones 


Family 


Medical Coverage for May 
2001 


$455 



Once the invoices have been created via the "Generate Monthly Invoice Step" 
they can be previewed and finally posted. The posting process copies the invoice totals 
to the G/L table and updates all necessary account balances. This step can be 
considered the final "quality check" before the bills are sent to the customer. Once an 
10 invoice is posted to the G/L account it can be changed only through reverse entries to 
the system. The actual G/L activity that takes place when an invoice is posted depends 
upon the bill type of the invoiced policy. If the bill type is standard, then the invoiced 
charges are moved into the vendor holding account and the invoice is marked as posted. 
If the policy is a non-standard bill type, then the invoice charges are split into the vendor 
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liability account and the vendor accounts receivable account for the remittance and 
commission amounts respectively. This invoice is then marked as paid in full. 

In the course of business, carriers may adjust their rates and ask to have the rates 
retroactively applied to customer accounts. The following outlines how this example 
5 works in accordance with a preferred embodiment. Any carrier adjustments occur after 
the monthly billing cycle, i.e. once the monthly billing is completed. This cycle also 
uses the monthly configuration profile to determine how to apply the rate changes. All 
rate changes are handled by reverse entry line items. For example, Joe's employees 
have policies from Aetna and Cigna. In May 2001, Cigna notified the integrated system 
10 10 that their rates changed and that this change is effective as of February 2001 . In 
March 2001, one of Joe's employees, Terry, left the company. However, according to 
this change, Joe still needs to pay the rate change for the months of February and March. 



Table 9 



;Plan 


Policy Holder ' 


. .Coverage ' 


Start . 
Date: ' 


:.,End.v 
• Date ^ 


Last 
. Invoiced 


Remarks 


AET01 


Patrick Houle 


Family 


02/01 




05/01 




AET01 


Mark Petins 


Family 


04/98 




05/01 




AET01 


Terry Isaks 


Family 


01/98 


03/01 


03/01 


Currently 
inactive 


CIG01 


Bob Jones 


Individual 


02/01 


04/01 


04/01 




CIG01 


Bob Jones 


Family 


04/01 




05/01 
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Table 10 



Plan 


Policy 

TT 1 J 

Holder 


Coverage 


Description 


Rate 


AET01 


Patrick 
Houle 


Family 


Medical Coverage for May 2001 


$435 






AET01 


Mark 
Petins 


Family 


Medical Coverage for May 2001 


$435 


CIG01 


Terry Isaks 


Family 


Reversed Medical Coverage for Feb 

r\ f\f\ -I 

2001 


($455) 


CIG01 


Terry Isaks 


Family 


New Rate Medical Coverage for 
Feb 2001 


$475 


CIG01 


Terry Isaks 


Family 


Reversed Medical Coverage for 
Mar 200 1 


($455) 


CIG01 


Terry Isaks 


Family 


New Rate Medical Coverage for 
Mar 2001 


$475 


CIG01 


Bob Jones 


Family 


Reversed Medical Coverage for Feb 

OA A 1 

2001 


($455) 


CIG01 


Bob Jones 


Family 


New Rate Medical Coverage for 

T" 1 1- O AA 1 

Feb 200 1 


$475 




Bob Jones 


Family 


Reversed Medical Coverage for 
Mar 200 1 




CIG01 


Bob Jones 


Family 


New Rate Medical Coverage for 
Mar 200 1 


$475 


CIG01 


Bob Jones 


Family 


Reversed Medical Coverage for 
Apr 2001 


($455) 


CIG01 


Bob Jones 


Family 


New Rate Medical Coverage for 
Apr 2001 


$475 


CIG01 


Bob Jones 


Family 


Medical Coverage for May 2001 


$475 



When a payment is received from a client, several steps are followed as detailed in the 
subsequent table. 



Table 11 



Payment Arrives 


A system staff member receives a check in the mail 


Find Client 


Search for the client in the system and display all open invoices. 


Apply Payment 


Apply the payment to one or more invoices. 


Complete 
Payment 


If the payment amount exactly matches the outstanding invoice(s), 
then apply the entire amount and mark the invoice(s) closed. 


Partial Payment 


If the payment amount does not match the outstanding invoice(s), 
then apply the received amount to the invoice and mark the invoice 
"partially paid." 


Overpayment 


If the client overpays, then need to issue the client a credit. (Need 
to determine the process for handling this occurrence) 
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An exemplary bill payment in accordance with a preferred embodiment is illustrated 
hereinafter. 



Table 12 











Employee Plan 100 


Carrier A 


$250 


$250 


Employee Plan 200 


Carrier B 


$100 




Employee Plan 110 


Carrier A 


$300 


$300 












Invoice Total 


$650 






Received 




$550 



In this example, the entire payment is held until the invoice is paid in full, even though 
carrier A received his entire payment amount. 
5 The following steps take place when a payment is applied and include, the user 

selecting a customer to apply a payment against, the user selecting a deposit account to 
place the payment in, the user is presented with a list of all invoices that are not marked 
as paid in full, and the user selecting invoices .from the list and specifying amounts to 
apply to each invoice (apply-amounts). The user is given the option to apply any 

10 account credits with this payment. If the payment amount is greater than or equal to the 
apply-amounts, then the credit is not be used, the payment amount plus credits (if 
applicable) can be greater than or equal to the total of the apply-amounts or an error 
occurs. The process for payment application also includes the system creating a 
payment detail entry for each invoice specified. If the payment amount plus credit 

15 amount is greater than the total apply-amounts, then a credit is created associated with 
the current payment and is associated with overpayment. If a credit is created, then the 
account credit total is.updated, if a credit or a portion of a credit is used, then existing 
credit payment entries associated with the account are updated appropriately. The 
account credit total is adjusted accordingly for any changes here. Further, the invoice 

20 received amount and balance are updated to reflect the payment and possible credit 
application. When an apply-amount is applied to an invoice, apply-amount is moved 
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from the vendor holding account and split into the vendor liability account and vendor 
accounts receivable account for the remittance and commission calculated for 
applyamount. If the invoice balance = $0, then the invoice is marked as "paid in full" 

If the invoice receive balance > $0 and invoice balance > $0 then the invoice is 
5 marked as "partially paid." 

The following example illustrates the stream of events followed when applying a 
payment. If there are the following 2 invoices 



Table 13 



Invoice ID 


• Amount 


. Received 


, Balance 


Status. ' 


INV01 


$250 


0 


$250 


Unpaid 


INV02 


$200 


0 


$200 


Unpaid 



Now a payment PI is received for $500 and is applied to the above invoices as follows: 



Table 14 



Payment ID > ' 


Amount 


Invoice ID c 


Is Credit? 


PI 


$250 


INV01 


No 


PI 


$200 


INV02 


No 


PI 


$50 




Yes 



At this point, 3 payment detail entries are created, one for each invoice that the payment 
10 is applied to and one for a credit amount left over from the payment. This overpayment 
is also recorded in the Account entry for the account associated with the invoice. 
For another invoice, INV03 as shown below: 



Table 15 



Invoice ID 


Amount 


Received 


Balance 


Status . - 


INV01 


$250 


$250 


$0 


Paid in Full 


INV02 


$200 


$200 


$0 


Paid in Full 


INV03 


$245 


$0 


$245 


Unpaid 
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and a new payment for $245, P2, is applied to that invoice. The user also chooses to 
apply credit to the invoice. The existing payment detail credit for $50 is deleted, and 
replaced with a detail for $45 and a detail for a $5 credit. The Account Credit field is 
updated accordingly to equal $5. 



Table 16 











PI 


$250 


INV01 


No 


PI 


$200 


INV02 


No 


PI 


$45 


INV03 


No 


PI 


$5 




Yes 


P2 


$245 


INV03 


No 



5 This leaves the invoices looking like the following: 



Table 17 













INV01 


$250 


$250 


$0 


Paid in Full 


INV02 


$200 


$200 


$0 


Paid in Full 


INV03 


$245 


$245 


$0 


Paid in Full 



FIG. 15B illustrates a flowchart 700 detailing the carrier remittance subsystem 
600 process flow as part of the vendor billing subsystem in accordance with a preferred 
embodiment of the present invention. The carrier creates a remittance header per step 
702. The system then generates a payment identifier per step 704. All unremitted 

10 customer payments from the carrier liability account are then loaded into the identifier 
per step 706. Payments are then applied to the accounts receivable items in step 708. A 
determination is then made to ascertain if the payment is equal to the applied amount in 
step 710. If there is an overpayment then the carrier liability account is credited per step 
712. If there is an underpayment then the carrier liability account is debited. The 

15 remitted amount is created as a remittance detail per step 714. The general ledger entry 
is created in step 716 followed by updating the account balance in step 718. 
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FIG. 15C illustrates a flowchart 740 detailing the carrier payment subsystem 
602, in particular the process for paying a commission, included in the billing subsystem 
in accordance with a preferred embodiment of the present invention. The carrier creates 
a payment header per step 742. A system payment identifier is then created per step 
5 744. The process includes loading all unpaid carrier commissions from the carrier 
accounts receivable (A/R) account in step 746. The payments are then applied to the 
A/R items in step 748. It is then determined per step 750 if the payment equals the 
applied amount. If an overpayment has occurred then per step 752 the carrier payment 
credit is created and the process continues to step 754. If there is an underpayment then 

10 the carrier payment account is debited. If the remittance is the full amount then in step 
754 a carrier payment detail is created. A general ledger entry is then created per step 
758 by updating the account balance. It should be noted that carrier commissions are 
created when an invoice is posted or paid partially or in full during the billing process as 
described with respect to the posting of invoice process flow. When a carrier 

15 commission is created, an A/R note is generated for the carrier. The billing system 
contains minimum maintenance screens which permit the billing agent to access or 
change the billing tables that are stored in the system database. In a preferred 
embodiment, all changes are made through the administrative application: The 
preferred embodiment includes the ability to change the policy history table, delete an 

20 unposted invoice, adjust a customer account, i.e. write-off an invoice line item, edit an 
unposted invoice, reverse entry an invoice line item, and create a manual invoice. 

When the billing agent logs into the CRM system using a user interface in a 
computer, the user sees a custom menu on the navigation bar: "billing." Clicking on 
this menu evokes a custom screen which offers the user the ability to: generate monthly 

25 invoices, review invoices, generate statements, review statements, review overdue 
accounts, receive payments, review payments, create remittance, review remittance, 
receive commission, review commission and to view a balance sheet, pay invoices, 
review payments, make adjustments, create remittances, review remittances and to view 
a balance sheet and profit and loss statement. 
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The generate monthly invoices screen uses the profile history table to determine 
which accounts should be billed during the indicated period. In a preferred embodiment 
of the system, the billing period can be the first of the month. All invoices are created 
with an invoice date of the first of the month. The generate invoice process follows 
5 these steps in order to create invoices: the user selects a month (i.e. invoicing period), 
active accounts are loaded from the account table, active policies are loaded from the 
policy table, and the policy history table is used to determine which employee's to bill 
and which plans at what rate to invoice. 

Initially, all invoices are created with an unposted status. This allows the billing 
10 agent to check the invoice for accuracy before posting it to the general ledger account. 
Once an invoice is posted, it can only be changed via reverse entries to the general 
ledger. 

The review invoices list contains a list of all of the invoices in the system, 
included unposted, posted, partially paid and fully paid invoices. This list is displayed 
15 once the generate monthly invoices is successfully completed. The review invoices 
displays the invoice number, invoice date, CRM id, client name, invoice amount and 
invoice status. 

Unposted invoices contain a check-box next to the invoice status. The billing 
agent can post any unposted invoices, by selecting the invoice and pressing the post user 
20 interface button. 

The generate statements screen allows the billing agent to create a statement for 
the customer that covers a particular date range of charges and payments. In order to 
generate statements, the billing agent must select the accounts that statements should be 
generated for, a statement month, and a statement date range ending date. The ending 
25 '"date allows the agent to specify the period of charges that will be considered for the 
statement. This date defaults to the current date. 

Initially, all statements are created with an unposted status. This allows the 
billing agent to check the statement for accuracy before posting it. Once a statement is 
posted, a statement hardcopy is generated and the statement can no longer be deleted. 
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The review statements list contains a list of all the statements in the system. 
This list is displayed once the generate statements operation is successfully completed. 
The statement list displays the statement date, statement number, customer name, CRM 
id, statement status, new charges, payments-received, previous balance and balance due. 
5 The review overdue accounts screen allows the billing agent to review accounts 

that are overdue for a particular statement period. If any overdue accounts are found, 
then the system allows the billing agent to generate overdue notices that can be sent to 
the customer. The billing agent can choose to produce a first notice, second notice or 
termination notice document for the overdue accounts. 

1 0 The pay invoices screen allows the billing agent to pay one or more posted 

invoices. To pay an invoice, the billing agent selects the system account, fills in the 
check amount, date received, a reference number (i.e. check number) and a description 
(optional), and selects a system asset account . At this time, one or more invoices can 
be paid. In a preferred embodiment, payment must be made against each outstanding 

15 invoice. If the payment equals the invoice total, then the invoice is marked paid in full 
and is not displayed on this screen in the future. If the invoice is partially paid, then the 
invoice status is set to "partially paid" and is displayed until it is paid in full. If at any 
time the billing agent does not apply the total payment to one or more invoices, the 
balance is credited to the customer's account. Credits can be applied to outstanding 

20 invoice balances at any time. 

In a preferred embodiment the billing system handles simple account transfers 
using the adjustment screen. This screen enables the billing agent to move money from 
one account to another. In another preferred embodiment the billing system includes 
write-offs, reverse entries, overpayment adjustments and underpayment adjustments. 

25 In a preferred embodiment the billing system generates a carrier remittance at the 

time the invoice is posted or paid partially or fully. The remittance is calculated based 
on the carrier schedule which is setup for the policy. Once a carrier remittance is 
generated, the system allows the billing agent to review previous transactions. In 
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another preferred embodiment, the billing agent can change a past payment or make 
adjustments to the payment, i.e. via a reverse journal entry. 

The preferred embodiment provides a basic balance sheet (B/S) and profit and 
loss (P/L) report. For any account within the B/S or P/L, the details behind the number 
5 can be easily viewed by clicking on the chart of account number. The billing system 
includes a "double-entry" accounting program. The system contains a chart of accounts 
which keeps track of all accounts in the system. The program contains the following 
standard accounts in accordance with a preferred embodiment: 



Table 18 



Chart of Account 


Description: ~ , ' ; ; ; .'V^®*" 


Accounts Receivables 


Account which keeps tracks of outstanding invoices 


Premium Income Account 


Account to track income from monthly premium 
billing charges 


Finance Charge Income Account 


Account to track income from finance charges 


Carrier Liability Account 


Each carrier will have a corresponding liability 
account which keeps track of premium which need to 
paid out. 


Cost of Goods Account 




Sales Person Commission 
Liability Account 


Each sales person will have a corresponding liability 
account which keeps track of commissions which 
need to paid out. 


Sales Person Expense Account 


Each sales person will have a corresponding expense 
account which keeps track of commissions 


Retained Earnings Account 


Short term profit account 


Revenue Account 


Company profit account 


Cash Account 


Basic "Savings" account for the company 



10 In general the billing system further contains the following base tables: 
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Table 19 







Chart of Accounts 


Contains all of the accounts listed above 


Invoice Header 


Tracks all of the invoices sent to customer 


Invoice Detail 


Tracks the details of the invoices. . 


Payment Table 


Track all payment received from clients 


Customer Table 


Tracks all of the customers in the system. Note: This 
table will mostly be called the "Account" table 


Carrier Table 


List of all carriers in the system. Note: This table is 
the AR Vendor table. 


Item Table 


Keeps track of all of the items which can appear on an 
invoice 


Transaction Table 


Tracks all of the transaction which occur in the billing 
system. Note: the Income Statement and Balance 
Sheet will be derived from this table. 



The application in a preferred embodiment is a web-based application operable 
with most of the standard commercially available browsers. The program' s instructions 
are designed using Microsoft's n-tier architecture, utilizing ASP for the client front end, 
VB COM objects for the business and data tiers and SQL Server for the database 
system. The preferred embodiments are cross-browser compatible, and scaleable to tens 
of thousands of simultaneous users per day. 

FIGS. 16A-1, 16A-2, 16B-1 and 16B-2 illustrate table diagrams used in the 
enrollment subsystem for the integrated insurance system in accordance with a preferred 
embodiment of the present invention. FIGS. 17A-1, 17A-2, 17B-1 and 17B-2 are table 
diagrams used in the billing subsystem and support subsystems in accordance with 
preferred embodiments of the present invention. 

The system 10 servers store a plurality of databases including tables. Certain 
terms are used in the database architecture herein have specific definitions. Many of 
these terms are used generically in the industry to represent certain concepts related to 
databases. The database is a collection of tables. A table can be a collection of records. 
Each record is a collection of fields. The preferred embodiments of the present 
invention use a record structure that allows tracking of particular data through all the 
subsystems. The relationships between the subsystems are managed by the record 
structures that provide access to common data. The database can contain any number of 
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tables. In practice, the database contains as a minimum several tables such as the tables 
described in FIGS. 16A-1, 16A-2, 16B-1, 16B-2, 17A-1, 17A-2, 17B-1 and 17B-2 with 
respect to the quoting subsystem, enrollment subsystem, billing subsystem and support 
tables. The database structure can be defined as the interrelationships between tables. 
5 A function of the server is to collect and assemble data from disparate and existing 
sources. These sources may consist of files, third-party databases, or even a website. 
The keys function as pointers to access the data stored in the database. There is a 
primary key in a table as well as a foreign key (FK) which typically points to another 
table. The strings (STR) are used as opposed to numbers in the particular fields. These 

10 strings are randomly generated, global unique identifiers for each geographic location. 
During a merging process these strings are easily combined without losing the unique 
information for each geographic location. 

FIGS. 18A-18B illustrate flow diagrams detailing exemplary interactions for the 
employer portal and the employee portal, respectively, in accordance with a preferred 

15 embodiment of the present invention. FIG. 18A illustrates a flowchart 1200 describing 
exemplary interactions with the employer portal and various subsystems in the 
integrated insurance systems 10. In this example, if an employer includes additional 
employees, the employer company may be subjected to new rates based on carrier rules 
regarding different criteria, for example, number of employees. In this embodiment, the 

20 employer receives new rates through the quoting subsystem 1210, and changes to the 
enrollment 1212 and billing subsystems 1214. The CRM subsystem 1208 maybe 
updated with the revised employee count. For any employee entering the employee 
portal, the employee can view the new rates quoted or changes to their individual 
enrollment profile. The database 1218 is accessed by the system portal services to 

25 update the enrollment and or billing tables. 

FIG. 18B is an exemplary flowchart 1250 describing interactions between the 
employee portal 1252 and various subsystems in the integrated insurance system 10. If 
an employee accesses the employee portal 1252 and changes any shared information 
fields, the actions can result in changes to several subsystems within the employee 
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portal and perhaps those in the employer portal. In both the portals, the CRM 
subsystems 1258, 1272, quoting subsystems 1260, 1274, enrollment subsystems 1262, 
. 1276, billing subsystems 1264, 1278 and underwriting subsystems 1266, 1280 can be 
affected. The same effect can occur by changing other shared information such as, for 
5 example, social security number, date of birth, marital status and coverage election such 
as individual versus family coverage. 

FIG. 19 illustrates a view of a display screen 1300 that a user interfaces with in 
order to allow an account executive to view which users have access to the system in 
accordance with a preferred embodiment of the present invention. The CRM system 

10 interface in accordance with a preferred embodiment is customized to include 

functionality which is intended to be used by classes of the system employees who 
administer the system. These administrative functions include creating new accounts, 
reviewing invoices and payments and generating customer payments. The custom CRM 
menu options are available to three classes of system users: account executives (AE), 

15 customer service representatives (CSR) and billing agents. In a preferred embodiment, 
the CRM custom portal can be found at a universal resource located such as 
https://secure.valuebenefits.com/ep_web/. The CRM system has multiple groups of 
users, for example, sales, customer services, finance, executives and administrators. 

In the CRM system, the account executives have access to at least two functions, 

.20 for example, viewing a customer account, viewing previous quotes and managing access 
to the system. The first function provides a simple way for the account executive to 
preview the customer's basic account information. This screen contains the account 
name, address and contact information as well as which policies have been setup for the 
account. The AE cannot make any changes to the information in the system. 

25 The second function includes the ability to view, or edit customer quotes. 

Additionally, the AE can review existing quotes, edit a quote or delete a customer quote. 
In a preferred embodiment a quote to an account need not be attached. . 

In a preferred embodiment, a separate quoting tool is provided for the account 
executive. This tool is optimized for the AE to generate quotes for the customer which 
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includes medical, dental, term life, short term disability and long term disability. This 
embodiment of the system is optimized for the account executives to quickly generate 
quotes. The system is tightly coupled to the account profile information, thus reducing 
the amount of information they must enter to generate a quote. 
5 The quoting system is revised to determine which lines of coverage need to be 

quoted, what the employer's contribution is for each elected coverage and which 
employees select which lines of coverage. Display screens gather information for 
electronically producing a quote for ancillary lines of coverage. The AE is able to view 
a history which employees chose which cards. 
10 As illustrated in the user interface display screen 1300, the account access link 

allows the AE to quickly view which users have access to the system and to manage 
access to the system. The setup link opens the setup account access screen, which 
allows a user to change the log in name 1302, password 1304 and password expiration 
date 1306. 

15 The login link opens a new browser to the employer portal with the AE already 

logged in. In a preferred embodiment, the AE does not need to set up a username or 
password to log into the employer portal. The username and password are used by the 
customer to log in. 

FIG. 20 illustrates a view of a display screen that a user interfaces with in order 
20 to log into a portal and set up an account access in accordance with a preferred 

embodiment of the present invention. In a preferred embodiment, the setup account 
access screen 1350 is used to manage the user's name, password, expiration date and 
access permissions. The expiration date is the date the password expires. The access 
permissions determine what a user can see when they log into the employer portal. 
25 Selecting by checking the portal permission 1352 allows the customer to enter the 

portal. Selecting by checking the quoting permission 1354 allows the customer to view 
or create quotes in the portal. Checking or selecting the public 1356 and private 1358 
enrollment permissions allows the customer to review or enter enrollment information 
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in the portal If the log into portal save checkbox is selected or checked, then a window 
opens to the employer portal when the user presses save. 

FIG. 21 illustrates a view of a display screen 1370 that a user interfaces with in 
order to view account information in accordance with a preferred embodiment of the. 
5 present invention. The account executive can access and view the account information 
which includes an account key, name, type and status, without limitation. 

FIG. 22 illustrates a view of a display screen 1400 that a user interfaces with to 
view quotes in accordance with a preferred embodiment of the present invention. The 
user in this case is the account executive who can view the quote name, company, quote 
1 0 date and effective date at the very least. 

FIG. 23 illustrates a view of a display screen 1450 that a user interfaces with in 
order to access the account as part of the customer service menu option in accordance 
with a preferred embodiment of the present invention. This screen is accessed to set up 
quotes for an account or to post the setup login to the system. Thus the preferred 
15 embodiments of the system contain a complete on-line enrollment system. The 

enrollment system is designed to be used by either an Employer or a Customer Service 
Representative. The on-line enrollment system gathers all of the information required 
by the carrier. Either the system administrator or an Employer can review this 
information on-line. The enrollment information can be relayed back to the carrier in 
20 several formats, including comma-delimited, ANSI format or Adobe Acrobat® (PDF) 
files. 

FIG. 24 illustrates a view of a display screen 1470 that a user interfaces with 
from within the CRM system in order to view the account information and enrollment in 
accordance with a preferred embodiment of the present invention. The account 
25 information provides user specific information. The enrollment profile includes the 
information for the plans, rates for specific employees of the employer. 

FIG. 25 illustrates a view of a display screen 1500 that a user interfaces with in 
order to view the invoices from within the CRM system in accordance with a preferred 
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embodiment of the present invention. The invoices are listed by invoice number, 
company, invoice date, amount and status. 

FIG. 26 illustrates a view of a display screen 1550 that a user interfaces with for 
" viewing invoice details from within the CRM system in accordance with a preferred 
5 embodiment of the present invention. The invoice details that can be reviewed include 
information about the employer client and specific information about each of the 
employee enrollees. 

FIG. 27 illustrates a view of a display screen 1570 that a user interfaces with for 
viewing payments from within the CRM system in accordance with a preferred 

10 embodiment of the present invention. The payments are presented in a list format with 
payment numbers, comments, payment date, amount and status as details. 

FIG. 28 is a flowchart 1600 detailing the setup of a policy in accordance with a 
preferred embodiment of the present invention. The customer service activities include 
adding a policy per step 1602, setting up plans per step 1604, setting up sales roles per 

15 step 1606 and setting up policy holders per step 1608 and plans. In step 1602 the user 
interface actions include selection of type of policy, be it medical, life, dental, home, 
without limitation, setting effective dates of policy, entering policy name and number, 
entering a billing address for the policy and selecting a carrier responsible for the policy. 
The corresponding tables that are sourced for the addition of a policy include 

20 ENR_Policy and SYSJListitems. The user interface actions for the step 1604 for the 
setup of plans includes selecting one or more plans available for the policy holder to 
select from. The table links for the setup of plans includes, without limitation, 
ENR_PolicyPlans, CAR_Plans and SYS_Listitems. The business rules that apply for 
step 1604 include for the available plans selection based on employer's zip code, 

25 policy's effective range (from/to dates) and carrier effective on the policy. For step 
1606 the applicable screen actions include selecting one or more sales people and 
assigning their role in the sales i.e., account executive, manager, vice president. The 
corresponding table links include, without limitation, ENR_PolicyBroker, 
SYS_Brokers, and SYSJListitems. 
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For step 1608 the screen actions include, but are not limited to, selecting 
available employees, available plan from setup plans, assigning a coverage level i.e., 
individual, or family where appropriate, inserting optional information, such as gender 
or social security number (SSN) and assigning a manual rate if applicable. The 
5 corresponding table links include ENR_PolicyHistory, ENR_PolicyPlans, 

SYS_StateTierLevel, ENR_Employees, CONJndividuals, SYS_Listitems, without 
limitation. 

The step 1608 for setting up policy holders and plans include business rules, for 
example, policy holders have to be enrolled under the company assigned to the policy, 
10 the available plans need to be selected from plan setup items, coverage types have to be 
selected from carrier coverage types for the area based on, for example, employer zip 
code, plan rate (non-manual only), have to be selected based on plan chosen, on policy 
effective dates and on employer's zip code. 

The finance activities screen actions for step 1610 of finalizing policy includes 
1 5 setting the commission dates, if appropriate, setting the carrier commission schedule, 
remittance method and billing method. The corresponding table links include, without 
limitation, ENR_Policy, CAR_Schedules, and SYS_Listitems. 

The screen actions that are associated with the step 1612 to activate policy 
include, without limitation, setting the billing status to active, which initiates customer 
20 billing. The corresponding table link includes, without limitation, ENR_Policy. 

FIG. 29 illustrates a view of a display screen 1650 that a user interfaces with in 
order to view a policy in accordance with a preferred embodiment of the present 
invention. The view policy(s) screen has a link to allow the customer service 
representative to select the plans available during enrollment. The plans link 1652 
25 opens the map plans to policy screen. 

FIG. 30 illustrates a view of a display screen 1700 that a user interfaces with in 
order to enter all pertinent information when adding a new policy in accordance with a 
preferred embodiment of the present invention. The customer service representative 
accesses the screen to enter all the pertinent information when adding a new policy. The 
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system is password protected including the quoting system which details how the typical 
user interacts with the system. 

A preferred embodiment includes the automation of many of the current 
processes. For example, an alternate preferred embodiment system relies heavily on the 
5 customer service representative (CSR) tracking changes to the account in order to check 
enrollment eligibility. Preferred embodiments handle these responsibilities, by 
incorporating carrier eligibility logic or executable instructions into the system and 
alerting the customer service representative to possible problems. Another preferred 
embodiment of the system includes the electronic transfer of data between the system 
10 and the carrier partners or vendors. As carriers accept electronic enrollment and billing 
data, preferred embodiments include manual creation of data and sending of electronic 
files to the carrier. Preferred embodiment of the system automate this process and track 
transfers to ensure that the operation is successfully completed. 

The second custom menu within the CRM system is for the customer service 
15 representatives. The CSR has the ability to: view customer account information, view 
invoices, view customer payments, create new accounts and view existing policies. The 
account information screen is the same as the AE's view. 

The ability to review customer invoices and payments is provided for trouble 
shooting and handling customer inquiries. These views provide a list of which invoices 
20 were generated for the account and a list of payments which have been received by the. 
customer. The CSR can review the details of any invoice or payment by clicking on the 
invoice or payment id. The CSR can not change any information on these screens. 
The last two menu items, create new accounts and view policies, are directly 

i 

related to setting up and maintaining customer accounts. The CSR is responsible for 
25 initiating and completing the enrollment process. These last two menu options provide 
the CSR with this capability. The CSR creates a account by clicking on the "create new 
account" link within the CRM system. In a preferred embodiment, the CSR enters the 
account name, the sales person's name and a password for the account. The reporting of 
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sales commissions is tracked by the screen which assigns an AE to the account, 
(ENRJPolicyBroker). 

Once the information is saved, the CSR sets up a policy for the account. By 

saving this information, the CSR creates an account record, company record and policy 

5 record in the system. At the start of the enrollment process the customer's account 
status is set to "inprogress" and the policy status is set to "inprogress." These statuses 
are used to track the progress of the enrollment process, as well as to activate the billing 
process. 

The enrollment process is completed by the CSR within the CRM system via the 

10 following steps. First, the CSR selects the "pending" medical policy from the CRM 
system by clicking on the "medical" link. After reviewing the information on the 
screen, the CSR presses the save button. This action causes the following to occur: the 
policy status is set to "active," the account status is set to "activated," and all employee, 
plan and rate information is copied to the policy history table. An account must be 

15 activated in order to initiate billing. 

FIG. 31 illustrates a view of a display screen 1720 that a user interfaces with in 
order to map plans to a policy in accordance with a preferred embodiment of the present 
invention. When a new policy is setup, the customer service representative has the 
ability to determine which plans are displayed in the enrollment process. The add single 

20 item (>) 1722 and add all items (») 1724 buttons allows the CSR to add all of the plans 
to the policy. The remove single item (<) 1726 and remove all items («) 1728 buttons 
allows the CSR to remove all of the plans on the policy. Only plans which are added to 
the plan for policy list are displayed in enrollment. For example, the customer can only 
see the two plans, EMPNY002 and EMPNY004 in the plan select screen 1 730. 

25 FIG. 32 illustrates a view of a display screen 1750 that a user interfaces with in 

order to assign sales roles as part of the enrollment process in accordance with a 
preferred embodiment of the present invention. This screen 1750 sets up which sales 
people are assigned to the policy. The screen allows a user to setup one or more sales 
people and to define their specific role in the sales process. 
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FIG. 33 illustrates a view of a display screen 1780 that a user interfaces with in 
order to set up policy holders in the enrollment process in accordance with a preferred 
embodiment of the present invention. The screen 1780 allows the user to add one or 

more employees to the active policy. - . . . ... 

5 In a preferred embodiment, discount cards are included in the enrollment 

process. The CSR can add one or more cards for one or more employees. The available 
discount card list contains a list of all of the currently available discount cards. The 
employees list contains a list of all of the employees who have been setup on the 
account. The start/end dates represent the effective dates of the discount cards. The 
10 business rules associated with this screen include the provision such that any changes to 
the discount card options are immediately made to the billing system. 

FIG. 34 illustrates a view of a display screen 1850 that a user interfaces with in 
order to list all the policies in the particular account and indicate different status in 
accordance with a preferred embodiment of the CRM/billing system of the present 
15 invention. The finance menu options are available from within the CSR system for all 
users who have rights to the finance group. The CRM system has at least five groups of 
users including sales, customer service, finance, executives and administration. The 
finance section includes the addition of the setup policy screen and the billing 
adjustment screens. These screens are used to review an account and to setup the items 
20 necessary to correctly bill the customer. 

The setup policy screen is retrieved by clicking on Account Info under the 
CRM/Billing menu. This screen lists all of the policies on the account and indicates 
their current billing status. The details link 1852 allows the billing agent to review the 
enrollment information for the policy. The setup link 1854 displays the policy details 
25 and allows the billing agent to change items related to billing. 

FIG. 35 illustrates a view of a display screen 1870 that a user interfaces with in 
order to set up or review the billing attributes of a policy in accordance with a preferred 
embodiment of the present invention. The setup policy is used to setup or review the 
billing attributes of a policy. The billing agent can set the commission start date, the 
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type of billing, net remittance versus gross remittance, and select the carrier schedule to 
use for remittance. Pressing the activate policy button marks the policy as active and 
adds the policy to the next billing period. In a preferred embodiment, the features 

~ - available to the billing agent are expandedto include salesxommission tracking and . _ 

5 broker of record (BOR) premium tracking. Additionally, the billing agent needs the 
ability to reconcile previous transactions such as payments received, carrier remittances 
sent and carrier commissions collected. The reconciliation process is important to 
ensure, that all of the chart of accounts remain balanced. 

In a preferred embodiment all of the billing features are available through the 

10 CRM system. When the billing agent logs into the CRM system, she/he views a custom 
menu on the navigation bar: "billing." Clicking on this menu evokes a custom screen 
which offers the user the ability to: generate monthly invoices, review invoices, pay 
invoices, review payments, make adjustments, create remittances, review remittances 
and to view a balance sheet and profit and loss statement. These features are described 

15 hereinbelow. . 

"Generate monthly billing" screen is the main screen for billing clients on a 
monthly basis. With the click of a button^ the system scans the accounts table and 
generate invoices for all active clients. Any supplemental charges which have been 
setup for the client are added on to the invoice at the end of the process. 

20 The generate monthly invoices screen uses the profile history table to determine 

which accounts should be billed during the indicated period. In a preferred embodiment 
of the system, the billing period can be the first of the month. All invoices are created 
with an invoice date of any day of the month. The generate invoice process follows 
these steps in order to create invoices: the user selects a month (i.e. invoicing period), 

25 active accounts are loaded from the account table, active policies are loaded from the 
policy table, the invoice table is scanned to be certain an invoice does not exist for the 
invoicing period, the policy history table is used to determine which employee's to bill 
and which plans at what rate to invoice. 
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The first screen in the generate (monthly) invoice step asks the user to select a 
billing period. The user selects a date from the drop down list. Upon pressing the go 
button, the review invoice list is displayed with the new invoices. Initially, all invoices 
are created with an unposted status. This allows the billing agentto check the invoice 
5 for accuracy before posting it to the general ledger account. Once an invoice is posted, 
it can only be changed via reverse entries to the general ledger. 

The review invoices list contains a list of all of the invoices in the system, 
included unposted, posted, partially paid and fully paid invoices. This list is displayed 
once the generate monthly invoices is successfully completed. The review invoices 

10 displays the invoice number, client name, invoice amount and invoice status. 

Unposted invoices contain a check-box next to the invoice status. The billing agent can 
post any unposted invoices, by selecting the invoice and pressing the post button. The 
business rules that apply include each account being invoiced once per month, if a bill 
already exists for the client for the specified month, then the bill is overwritten, 

1 5 however, the bill is not overwritten if it has already been paid, the create button scans 
the ENR_Accounts table to determine which clients are active and requires a bill for the 
specified period, if additional charges are setup for the client, they are added to the 
invoice. Further, when an invoice is created, the invoice amount is debited to Accounts 
Receivable and credited to the income account, any finance charges or miscellaneous 

20 charges which are not transferable, are credited to the retained earnings account, the 
invoice amount is added to the customer's outstanding balance in the chart of accounts, 
process for creating monthly invoices, load all active accounts, determine if an invoice 
already exists for the specified month, and determine if the Account has any active 
policies. 

25 The review monthly invoices screen allows the billing agent to review all of the 

invoices before they are posted to the general ledger. The link on the invoice number 
displays the "preview invoice" screen. By clicking on the checkbox next to the 
"unposted" invoices, the user can post all of the select invoices with one click. 
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The preview invoice choice displays a read-only version of the invoice. The pay 
invoices screen allows the billing agent to pay one or more posted invoices. To pay an 
invoice, the billing agent selects the system account, fills in the check amount, date 

received, a reference number (i.e. check number) and a description (optional), and . . ... 

5 selects a system asset account . At this time, one or more invoices can be paid. 
Payment must be made against each outstanding invoice. If the payment equals the 
invoice total, then the invoice is marked paid in full and is not displayed on this screen 
in the future. If the invoice is partially paid, then the invoice status is set to "partially 
paid" and is displayed until it is paid in full. If at any time the billing agent does not 

10 apply the total payment to one or more invoices, the balance is credited to the 

customer's account. Credits can be applied to outstanding invoice balances at any time. 

As the first step, the user must first select a account. Pressing the select button 
opens the review payments list. The business rules that apply include if the check 
amount does not equal the invoice amount, then the total amount is placed in a "holding 

1 5 account" and not the cash account, the check amount must equal the amount applied to 
the individual invoices, if a payment is applied to an invoice, the invoice is marked paid. 
Further, when payment is received, cash is debited from accounts receivables and 
moved to the indicated cash account. When payment is received, a carrier liability is 
created for the carrier listed on the invoice. The information at the top of the form is 

20 retrieved from BIL_Payments table. 

The review payments menu item displays a historical list of payments for a given 
date range and/or specific client. The user can preview the payment, by clicking on the 
payment ID, or edit the payment. The business rules that apply include, if a payment is 
deleted, then the associated invoices are unmarked as paid, a payment cannot be deleted 

25 if the Payment Status = Inreconciliation or reconciled, a payment cannot be edited if the 
Payment Status = Reconciled. 

A carrier remittance is generated at the time the invoice is posted or paid in 
accordance with a preferred embodiment. The remittance is calculated based on the 
carrier schedule which is setup for the policy. Once a carrier remittance is generated, 



{J:\CLIENTS\ip\082238\3000\3000-101\F0251479.DOC;!} 



082238.3000-101 

-75- 

the system allows the billing agent to review previous transactions. The billing agent 
can change a past payment or make adjustments to the payment, i.e. via a reverse 
journal entry. 

FIG. 36 illustrates a view of a display screen 1900 that a user interfaces with in - 
5 order to display enrollment policy details in accordance with a preferred embodiment of 
the present invention. The enrollment details screen 1900 displays all of the employees 
who have been setup on the policy. These employees are setup via the new enrollment 
for broker of record (BOR) enrollment process. The tables in the screen reflect all of 
the items in the billing history table ENR_ProfileHistory in the integrated insurance 
10 system. The billing agent has the ability to override any plans or rates or to make billing 
adjustments using this screen 1900. 

The adjustment link opens up the billing adjustment screen. This screen is used 
to change the billing profile in the event that a client has been incorrectly billed. Any 
billing adjustment which is made and which is used to calculate the next billing period 
15 rates is shown in the screen. It can contain a delete link because the profile history 
status is set to a default. 

The override link 1902 opens up the override screen. This screen is used to 
setup a broker of record (BOR)-type account, i.e., an account which is billed for non- 
standard system plans. 

20 FIG. 37 illustrates a view of a display screen 1920 that a user interfaces with in. 

order to display an override plan that is used to manually set a rate for a plan in 
accordance with a preferred embodiment of the present invention. The override plan 
screen allows the billing agent to manually set a rate for a plan. 

FIG. 38 illustrates a view of a display screen 1950 that a user interfaces with, in 

25 particular an employer or customer to log into the system in accordance with a preferred 
embodiment of the present invention. A password needs to be provided to proceed. 

FIG. 39 illustrates a view of a display screen 1970 that a user interfaces with in 
order to display customer specific information such as, for example, previous quotes 
and coverage profile in accordance with a preferred embodiment of the present 
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invention. This screen contains customer specific information, such as a list of previous 
quotes 1972 and current enrollment information. This page is accessible by clicking on 
a link, for example, my account link. 

FIGr 40 illustrates a view of a display screen 2000 that auser interfaces with in_ 
5 order to display a client or company profile in accordance with a preferred embodiment 
of the present invention. This screen includes company specific information such as 
billing address, contact name and geographic information. 

FIG. 41 illustrates a view of a display screen that a user interfaces with in order 
to display a list of employees or employee profile and corresponding employee 

10 information in accordance with a preferred embodiment of the present invention. 
Within the enrollment section all of the screens remain the same except for the enter 
employee information screen. This screen makes it easier for the account executives to 
enter employee information if no employee profile information exists. 

FIG. 42 illustrates a view of a display screen 2050 that a user interfaces with in 

1 5 order to perform a new rate comparison that includes entering of company information 
in accordance with a preferred embodiment of the present invention. Company name 
and address is entered in this screen. The pertinent business rules that apply to this 
screen include, without limitation, red asterisks representing required fields, generating 
a quote number automatically using a format, for example, xxx-counter and saving. In a 

20 preferred embodiment, the carrier files are stored in a carrier table. The rate comparison 
module of the system is geared towards providing small business groups with a 
localized rate comparison for group insurance products. A small business owner can go 
to the system's website and within 5 minutes generate a rate comparison of all of the 
carrier's which offer, for example, medical health plans in their area. The business 

25 owner need only enter several key pieces of information to generate a quote, including: 
a business zip code, total number of employees eligible for health insurance, each 
employee's demographic information and the employer's contribution. The business 
owner can customize the final quote to include only the carrier and/or plans which meet 
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his/her needs. The quote is automatically saved in a preferred embodiment for later 
retrieval. 

FIG. 43 illustrates a view of a display screen 2070 that a user interfaces with in 
....... . order to enter employee information to perform a new rate comparison in accordance . 

5 with a preferred embodiment of the present invention. When creating a quick quote an 
employer enters the employee's date of birth (DOB), sex and coverage type (individual 
policy, family policy, etc.). The employer can optionally enter the employee's name at 
this point. If the employer decides to set up more employees they can use the enter 
more employees list. 

10 FIG. 44 illustrates a view of a display screen 2100 that a user interfaces with in 

order to enter an employer contribution to perform a new rate comparison in accordance 
with a preferred embodiment of the present invention. The employer contribution 
screen allows the employer to enter a fixed or percentage amount to contribute to their 
employee's health care costs. The business rules included with the employer 

1 5 contribution are fixing a group level to start or dynamically generating them, 
contribution type list containing at least three fixed values, for example, flat fee, 
percentage and percent lowest and the same to continue link proceed to the compare 
plans page. 

FIG. 45 illustrates a view of a display screen 2150 that a user interfaces with for 
20 displaying a comparison of all the plans offered in accordance with a preferred 

embodiment of the present invention. The screen displays all of the plans offered by the 
system in the employer's area zip code. The business rules pertinent to this screen 
include the select plans link opening the select plan page, determining coverage rates by 
the employee's demographic information and the employer's zip code, defining the 
25 coverage types at the market level, the details link displaying the details of the quote for 
each employee and a link on the plan opens the plan details page which is, for example, 
a file such as a PDF supplied by the carrier. 

FIG. 46 illustrates a view 2200 of a display screen that a user interfaces with for 
displaying the comparison of the plan rate for each individual employee in the company 
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in accordance with a preferred embodiment of the present invention. The detail by 
employee page is called from the compare plans page. This screen shows the actual 
plan rate for each individual employee in the company. As to the pertinent business 

rule, the composite totals are composed of theaverage rate for each coverage level 

5 FIG. 47 illustrates a view of a display screen 2220 that a user interfaces with in 

order to selectively remove certain plans from a quote page in accordance with a 
preferred embodiment of the present invention. The screen displays all of the plans 
offered in the employer's zip code. 

The enrollment process is managed and controlled by either a system sales 

10 representative or a customer representative. The general process flow for new 

enrollment includes the following steps. The enrollment process is initiated by the 
system sales representative who hands over a new case to a customer representative. 
The customer representative sets up a new username and password for the employer and 
his/her privilege level is set to "employer." The customer representative creates new 

15 account in ENR_Accounts table. The account status is set to "new setup." The 
customer representative also creates a new policy for the account (ENR_Policies). 
When the account is setup, the carrier is selected based on feedback from the employer. 
The carrier specific underwriting rules are applied to the employer enrollment. A "set" 
of enrollment steps is created to the ENR_EnrollWizard from the SYSJEnrollWizard 

20 template. Note more steps can be added on during the enrollment process for other 
product types. The user is directed to the new enrollment application or wizard. The 
user enters all of the information from the wizard. The user completes enrollment. The 
system checks that all necessary information has been entered. The account status is set 
to "employer complete." In a particular embodiment, the customer representative 

25 ensures that all information is completed by the employer, including checking the 

employer information against carrier underwriting rules. In another embodiment, this 
verification process is done automatically. The underwriting rules are set up for each 
carrier and include testing such conditions as, for example, minimum participation. The 
customer representative sets up any remaining items, such as billing information. 
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Account status is marked "completed." The customer representative completes the 
enrollment which marks the account and the policy active for billing. All of the policy 
holder details are added and marked active. 

The business rules for enrollment include determining if this is anew accounts _ 
5 i.e. no account has yet been setup then only the enrollment application wizard is visible, 
the customer representative creates the account before the employer logs in, and all 
specific carrier rules are displayed to the employer (on a separate screen) when she/he 
logs in. 

FIG. 48 illustrates a view of a display screen 2250 that a user interfaces with in 
10 order to enroll in the integrated insurance system in accordance with a preferred 

embodiment of the present invention. The employer needs to fill out several predefined 
segments such as, for example, company information, and contribution level. The 
screen 2250 lists all the steps needed to complete the enrollment process along with 
links to each step. 

15 FIGS. 49 and 50 illustrate views of a display screen 2270, 2300 that a user 

interfaces with in order to enter all the pertinent information for an employer in 
accordance with a preferred embodiment of the present invention. The screen 
essentially collects the billing information for the employer. The business rules that are 
coupled to this screen include requiring all fields with a red asterisk, saving information 

20 to ENR_Company, ENRJPerson and ENR_Addresses and filling drop down menu lists 
from the SYS_Listitems table where the contact list category equals "ContactTypes" 
and the address list category equals "AddressTypes." 

FIG. 51 illustrates a view of a display screen 2350 that a user interfaces with in 
order to enter a level of employer contribution in accordance with a preferred 

25 embodiment of the present invention. The screen asks the employer to enter a level of 
contribution for each plan coverage type. The pertinent business rules include the 
amount column being a percent or dollar amount, having three types of contribution 
levels, for example, fixed, percent of lowest and standard percent, loading contribution 
type form SYS JListitems where the list category is "MedContributionTypes," saving 
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values to ENR_EmpContributions and marking the step "Contribution Level" complete 
in the ENR_Enroll wizard table. 

As part of the underwriting requirements certain guidelines are followed. For 

example, a minimum participation rule requires that a minimum number of employees 

5 participate in the plan offering. The equation for this rule is: 

Minimum participation = (Total Insured)/(Total Insured + Total Uninsured). 
The contribution policy requires that an employer contribute to the premium thereby 
reducing the employee premium. The rules can vary on one or more factors including, 
lowest plan offered or the tier level of the plan. Employer's contribution can be 
10 different for each coverage level (i.e., individual, spouse. . .), percentage or flat fee, and a 
percentage of the individual plan or of the lowest plan. 

FIG. 52 illustrates a view of a display screen 2370 that a user interfaces with in 
order to enter employee information in accordance with a preferred embodiment of the 
present invention. Name, birthdate and SSN have to be entered for each employee. 
1 5 There is an option to add or delete employees. 

FIG. 53 illustrates a view of a display screen 2400 that a user interfaces with in 
order to input or map which employee selected which plan at which coverage level. The 
employee plan chooser screen contains a list of all employees in the company and 
selection fields for the plan names and coverage levels. After saving this information, 
20 the customer can proceed to the next screen. By matching the employee to specific 
carrier plans, the preferred embodiment of the system can accurately determine which 
enrollment forms need to be filled in to complete the enrollment process. 

The applicable business rules that pertain to employee plan matching include the 
information being saved to ENR_PolicyHolder, which can require the copying over of 
25 other information from the ENR_Employee or CON_Person table, such as DOB, gender 
and SSN. Further, the plan rate can be looked up for each employee from the 
CAR_Plan table. This rate is based on the enrollment start date. The step of match 
employees to plans is marked complete in the ENR^EnrollWizard table. 
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FIG. 54 illustrates a view of a display screen 2420 that a user interfaces with to 
display a list of the employees with the corresponding forms needed to be filled in to 
complete the enrollment process. In a preferred embodiment this is the final screen in 
the enrollment application. The system application automatically matches up which 
5 enrollment forms are necessary for the selected plans. After reviewing and printing the 
forms, the customer completes the enrollment process. 

After selecting which carrier the employer chooses, each employee is then 
mapped to the individual plan offering. The business rules that apply include 
information being saved to ENR_PolicyHolder, and duplicating other information from 

10 the ENR_Employee or CON_Person table, i.e., DOB, gender and SSN, and providing a 
lookup for the plan rate (for each employee) from the CARPlan table. This rate is 
based on the enrollment start date and then marking the step "Match Employees to 
Plans" complete in the ENR_EnrollWizard table. A forms menu contains carrier 
specific forms including enrollment forms. The carrier forms are prepopulated with 

15 profile information to expedite the enrollment process. The account profile information 
includes company name, company address, employee names, employee addresses and 
dependent names and addresses. The employee enrollment forms contain the universal 
enrollment form for the system. A single form exists for each employee. Each form 
contains all of the information from the system already "pre-filled." The group 

20 enrollment form contains a copy of the carrier's group enrollment form. This can be a 
PDF file which is not filled in. 

Carrier forms include a carrier contract, benefit summary and summary plan 
document. The carrier contract contains a PDF of the carrier contract. This section may 
have information "pre-filled" based on the plans selected by the employer. The benefit 

25 summary document contains a PDF of the benefits summaries. This document is 
supplied by the carrier. The summary plan document contains a PDF of the benefit 
summaries. This document is also supplied by the carrier. 
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When displaying a list of employees, the system uses any employee information 
which exists under the employee profile. However, if no employee information, exists, 
then the add button is used to add a new employee. 

The corresponding business rules include all of the fields being required, the 
5 coverage types are defined by the market, the employer does not need to enter their 
actual employee's name, by default, the field contains "employee n", where "n" 
represents the employee count, the date of births cannot be future dates, the gender drop 
down list is filled with two fixed items: male and female, and the coverage type drop 
down list is filled with four fixed items: individual, individual plus spouse, individual 
10 plus children and family. In a preferred embodiment this list is dynamically generated. 
The add more employees drop down list is fixed with three items. 

Each carrier can use one or more of the underwriting guidelines described 
hereinbefore. When setting up a new carrier, it is imperative that their individual 
underwriting guidelines be determined and implemented in preferred embodiments of 
15 the system. 

When the system personnel sign a contract with a carrier to offer a carrier's 
plan(s) in a particular area, the system collects certain information from the carrier. 
This information includes the plan name and number, what type of policy category it 
falls into (Medical, Life, etc.) the effective dates of the plan and links to the plan 

20 description and benefit summary description(s). Carriers are only allowed to offer plans 
within the states they are licensed to sell insurance in. The system keeps track of which 
states the carrier is currently licensed. Furthermore, each plan has an associated start 
and end date which covers when the plan is effective. Each plan has associated with it a 
set of zip codes in which the plan is offered. Lastly, each plan has one or more rates. 

25 These rates may be affected by the Employee's age, coverage type or gender or the 
Employee's total number of eligible employees.. 

For example, each health carrier has approximately 5-10 plan schedules for each 
market. The schedules vary based on co-pay level, deductible, provision of prescription 
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coverage, and out-of-network options. Each plan has a benefit description which is 
mapped to the Market segment where it is being offered. 



Table 20 



A typical offering might be three 
schedules of benefits as follows: 
Plan Price Category 


Type of Plan 


High 


HMO (in-network and out-of-network) 


Medium 


HMO without prescription coverage 


Low 


PPO (in-network) 



The contact management services are responsible for maintaining the system's 
5 link to the customer. A sales person may establish the first link to the client. In this 
embodiment, the sales person needs to enter the prospect's name and address. The sales 
person then records conversations with the client. A well-defined "action" service 
assists in keeping in contact with the prospect. 

In a preferred embodiment a process flow for a typical contact scenario includes: 

10 Table 21 



Initiate Contact 


A sales person calls up a new prospect. The call list may be in the Contact 
system already with a status of "New Call" or the sales person could be 
working off a separate call sheet. 


Complete Contact 


While the sales person is talking with the prospect, she/he may wish to 
record notes on the conversation. The call notes are directly entered into 
the system. 


Follow-up 


The sales person may wish to schedule a future call with this prospect. 
She/he enters an action to "call the prospect next week." 



In a preferred embodiment, security features provide for limited access and 
identifies items individual groups can and cannot access. The security features are 
provided at the group "role" level rather than individual level. This practice simplifies 
programming and expandability. Any electronic data shipped by the system or received 
1 5 by the system web site is sent using SSL security (HTTPS). The security system 
includes page-level security (each application service provider (ASP) page verifies 
username and password), a SQL Server 7.0 table level security (user groups are assigned 
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table level access), for example, a secured web-access via SSL, a firewall protection to 
prevent unauthorized users from accessing internal computers, and system user security 
levels. 

The Garner Management Subsystem (CMS) is used to populate and manage 
5 information displayed in the quoting subsystem. When first logging into the CMS, as 
illustrated in FIG. 55, the tree control displays all the carriers for one of the states within 
the system. The system administrators are then able to filter the carriers by state, policy 
type, and carrier status, for example. The tree displays system (VBI). information by 
state, policy type, carrier, and carrier functions, for example. This allows users to find, 
10 view, and edit the needed information in a fast and concise manner. In an embodiment, 
a default state is used when first viewing the tree in order to limit the number of 
possible nodes loaded into the tree control for a faster loading time. If the loading time 
is still unacceptable, then a default policy type can also be used to speedup the first tree 
load. 

15 FIG. 56 illustrates a view of a display screen that a user interfaces with to filter 

the number of carriers in the CMS subsystem in accordance with a preferred 
embodiment of the present invention. The Carrier Filter Options include without 
limitation, for example, state, policy type, carrier status. The database actions include 
the following production tables that are used to collect the data for the tree- view: 

20 CAR_Carriers, CAR_PolicyTypes, SYS_States. 

The CMS subsystem includes policy type actions. A carrier has a mapping . 
between the state(s) and policy type(s) that the system provides business for. This 
mapping is stored in the (VBI) system through the CAR_PolicyTypes table. Therefore, 
the users are able to view current mappings, add carriers and/or remove carriers from 

25 mappings. The following table describes the process involved to determine policy type 
actions. 
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Table 22 



Artinn ♦ 




Dpcfrintinn 


User clicks on the Policy Type 
under a given state within the tree 
view (for example, Medical folder). 


Tree View 


User views all carriers that are currently mapped 
within the system (policy type/state). 


User clicks on the Add Carrier 
action node under the policy type. 


Tree View 


Users can add a carrier mapping for the 
state/policy type that they are currently on. 


User clicks on the save button. 


Add Carrier to policy 
type/state 


A new record is inserted into the production 
server (CAR_PolicyTypes table.) 


User dicks on the remove button 
beside the list of mappings. 


State/Policy Type 
Ust 


Users can remove a mapping for a carrier, state, 
and policy type. The production server is 
updated (CAR_PolicyTypes table.) 



FIG. 57 illustrates a view of a display screen that allows a view of the mappings 
between carrier, policy type and state in accordance with a preferred embodiment of the 
5 present invention. The users can view or remove carriers from a given state/policy type. 
The database actions that are associated with mappings between the carrier, policy type 
and state include the following. The list of earners featured within the search pull down 
control contains the carriers that are currently mapped with the current policy type/state. 
The list of mappings between a selected carrier, policy type, and state come from the 
10 CAR_Carriers, CAR_PolicyTypes, SYS_States tables stored on production. When the 
user removes one of the mappings, the system deletes a record out of the 
CAR_PolicyTypes table within the production database. 

FIG. 58 illustrates a view of a display screen 2590 that a user interfaces with to 
add carrier mapping to policy type and state. Users can add a carrier to a state/policy 
15 type mapping. The database actions that are associated with the addition of carrier 

mapping to policy type and state include the following. When the user adds a carrier to 
a policy type/state mapping a record is inserted into the CAR_PolicyTypes table within 
the production database. The list of carriers in the dropdown list is selected from the 
production server. This list comes from the CAR_Carriers table and the 
20 CAR_PolicyTypes table where all carriers are returned that are not currently mapped to 
the given state/policy type. 

Carrier Actions include providing the ability for users to view or edit 
information about the carrier including carrier base information such as, for example, 
location or contacts and account information. The following table describes the process. 
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Table 23 



Action 


Screen 


Description 


User dicks on the carrier's name 
within the tree view. 


Tree View 


User chooses the carrier they wish to edit or view 
information on. 


User dicks on the Edit link located 
to the right of the Carrier Info 
section. 


Carrier Details 


Users can edit general information about the 
carrier such as the carrier name and address. 


User clicks on the Edit link located 
to the right of the Account info 
section. 


Carrier Details 


Users can manage the carrier's accounts including 
holding, payables, income, and expense. 



FIG. 59 illustrates a view of a display screen 2600 that a user interfaces with to 
view carrier information in accordance with a preferred embodiment of the present 
5 invention. The users can view carrier information and accounts using the display screen 
2600. The database actions associated with viewing carrier information include the 
carrier information and accounts information being selected from the following tables 
within the production database: CAR_Carriers, BIL_Chart Accounts. 

An additional carrier action includes providing edits carrier regarding 

10 information. For example, users can edit an existing carrier in the system by clicking on 
the carrier's name within the tree view and then clicking on the edit links. Further, 
users can edit and carrier details general information about the carrier such as, for 
example, the carrier name and address as illustrated in the display screen 2620 shown in 
FIG. 60. In a preferred embodiment, the business rules include the system Carrier Num 

1 5 being unique within the system and activating the Save user interface to cause the 
system to update the current information in the live database. The database actions 
associated with editing carrier details include the following. When the user edits the 
carrier details information the record for that carrier within the system production server 
is updated. 

20 An additional carrier action includes editing of carrier accounts as illustrated in 

the display screen 2640 shown in FIG. 61 in the CMS subsystem in accordance with a 
preferred embodiment of the present invention. A user manages the carrier's accounts 

» 

including holding, payables, income, and expense. 
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The applicable business rules in a preferred embodiment include the use of the 
Save user interface button to update the carrier's account information within the live 
system. Database actions that are associated with editing carrier accounts include, for 

example, when the user edits the carrier account information, the records within the - 

5 BIL_ChartAccounts table are updated on the production server. 

The CMS system in accordance with a preferred embodiment, includes actions 
associated with the plurality of plans. The users can view, edit, and add plans to the 
system by clicking on the folder within the tree control under a given carrier. Users can 
filter the plans displayed within the plans list by entering an effective date and/or by 
10 selecting a group level. The following table provides a process flow for the plan 
actions. 



Table 24 



Action 


* Screen 


Description 


User clicks on the Plans folder within 
the tree. 


Plans List 


Information about a plan such as the plans 
descriptions and plan num. Users can filter the 
plans through an effective on date and a group 
level. 


User clicks on a plan listed. 


Edit plans 


Users can edit a plan currently in the system. 


User clicks on the Add Plans action 
node. 


Add Plan Details 


A plan is inserted into the live system and the 
user is returned to the plan list page. 


User clicks Save & Add Another 
Plan. 


Add Plan Details 


A plan is inserted into the live system and the . 
user is returned to the Add Plan Details screen 
so that they may add another plan. 


User clicks on the Add Plans action 
node. 


Add Plans 


Users can do a mass plan addition to the system 
for a given carrier (CAR_Plans table.) 


User clicks on the Edit Plans action 
node. 


Edit Plans 


Users can edit one or more plans for a given 
carrier. 


User clicks on the Activation action 
node. 


Plans Activation 


Users can do a mass update of the effective to 
date and status for a given carrier's plans; 



FIG. 62 illustrates a view of a display screen that a user interfaces with to view 
plans in accordance with a preferred embodiment of the present invention. When the 
1 5 user clicks on the Plans folder as displayed in the screen 2660, the right screen then 
allows them to view and edit information about plans for a given carrier. The database 
actions associated with viewing the plans includes the following. When the user clicks 
on the Plans action node under a given carrier, policy type, and state the information 
displayed within the Carrier plans list screen comes from the CAR_Plans table on the 
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production server. Further, the list of group levels is selected from the SYS_ListItems 
table on production. 

An additional plan action includes adding a plan as illustrated in FIG. 63 in 
accordance with a preferred embodiment of the present invention. Users can add anew- 
5 plan to the system by clicking on the Add Plans link as shown in the display screen 
2680 located on the upper right hand corner of the plans list page. 

In a preferred embodiment, the business rules that are associated with adding a 
new plan include the following. The effective from date must be less then the effective 
to date. The plan number is automatically generated using the carrier number and the 
10 next highest plan id. Further, activating the Cancel user interface icon brings the user to 
the plans list page. 

The database actions associated with the addition of a new plan include when 
the user adds a plan using the CMS subsystem, a new record is inserted into the 
CAR_Plans table within the production database. 

15 The CMS system further includes the provision for users adding one to many 

new plans to the system by clicking on the Adds Plans action node as illustrated in 
FIGS. 64A and 64B. The business rules associated with the addition of plans include 
the following. Effective from date must be less then the Effective to date. The plan 
number is automatically generated using the carrier number and the next highest plan id. 

20 Further activating the Cancel user interface brings the user to the plans list page. The 
associated database actions for when the user adds plan(s) using the CMS subsystem 
includes new records being inserted into the CAR_Plans table within the production 
database. 

A further plan action includes the ability for users to edit an existing plan in the 
25 system as illustrated in the display screen 2740 of FIG. 65 in accordance with a 

preferred embodiment of the present invention. The business rules associated with 
editing a plan include the following. Effective from date must be less then the Effective 
to date. Interfacing with the Save button saves the information to the system and 
interfacing with the Cancel button returns users to the plans list page. The associated 
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database actions include when the user edits a plan using the CMS subsystem, a record 
within the CAR_Plans table on the production server is updated. Note that any tables 
that use the CAR_plans table's data may not be updated, for example, the 

ENR^PolicyHistory table which stores a plan's carrier plan num and description. 

5 In accordance with a preferred embodiment, users can edit existing plan(s) in the 

system as illustrated in FIGS. 66 A and 66B in accordance with a preferred embodiment 
of the present invention. They first select the plans they wish to edit and then edit the 
selected plans at the same time. The associated business rules include the following. 
Effective from date must be less then the effective to date. Pushing the Save user 

10 interface button saves the information to the system and pushing the Cancel user 

interface returns users to the plans list page. In addition, the database actions associated 
with editing plans includes when the user edits a plan using the CMS subsystem, a 
record within the CAR_Plans table on the production server is updated. Note that any 
tables that use the CAR_plans table's data may not be updated, for example, the 

1 5 ENR_PolicyHistory table which stores a plan's carrier plan num and description. 

FIG. 67 illustrates a view of a display screen that a user interfaces with to 
activate a plan in the CMS subsystem in accordance with a preferred embodiment of the 
present invention. Users can do a mass update of plans' effective to date and status for 
a carrier. The database actions associated with the activation of plans includes the 

20 following. When the user clicks on the Activation action node under a given carrier, 
policy type, and state, the information displayed within the screen 2800 comes from the 
CAR_Plans table on the production server. The user checks the plans they wish to 
update with the new effective to date and status. The user either sets the plan to be 
active or inactive by checking or unchecking the checkbox beside each plan. The 

25 CARPlans table is updated on production. 

There are actions that are pertinent to different regions. Users can view, edit, 
and add regions to the system by clicking on the Regions folder within the tree control 
under a given carrier. Users can filter the regions displayed within the regions list by 
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entering an effective date. The following table provides a process flow for the actions 
by region in accordance with a preferred embodiment of the present invention. 



Table 25 



• Action <"'. 


Screen 


Description 


User clicks on the Regions folder 
within the tree. 


Regions List 


Information about regions such as the regions' 
plans and counties. Users can filter the regions 
through an effective on date. 


User clicks on a region listed in the 
view regions list. 


Edit region's 
information 


Users can edit a region's information currently in 
the system. 


User clicks on a region's plans list. 


Edit region's plans 


The user can edit which plans are mapped to a 
given region. 


User clicks on a region's counties 
list. 


Edit region's counties 


The user can edit which counties are mapped to 
a qiven reqion. 


User clicks on the Add Regions 
action node. 


Add Region Details, 
add region plans, 
add reqions counties 


A new region is inserted into the system. 


User clicks on the Activation action 
node. 


Activation Regions 


Users can do a mass update of the effectiveto 
and status on regions for a given carrier 
(CAR PlanZipcodes table.) 



The users can view or edit regions as illustrated in the display screen 2820 of 
5 FIG. 68. The database actions associated with editing or viewing the regions include 
when the user clicks on the Regions folder under a given carrier, policy type, and state,; 
the information list comes from the following production tables: CAR_Regions, 
CAR_PlanZipcodes, CAR_Plans, and SYS_County. 

FIG. 69 illustrates a view of a display screen that a user interfaces with to add an 
1 0 existing region to the system in accordance with a preferred embodiment of the present 
invention. As seen in the display screen 2840 the user fills in detailed information 
regarding the new region such as carrier and state. The business rules associated with 
adding a region include the following. Pushing Save & Continue user interfaces cause 
the information in the form to be saved to the system and then the user can proceed to 
15 the next step. Effective From/To dates are used in updating the PlansZipcodes table as 
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well as which plans will be available in the following screens. Further, pushing Cancel 
user interface brings the users to the list of regions. 

The associated database actions include, for example, when the user clicks on 

the Save & Continue user interface button on-the Regions Details Add screen, the 

5 system inserts a new record into the CAR_Regions table on the production server. 

FIG. 70 illustrates a display screen 2860 that a user interfaces with and chooses 
the counties that maps to a new region in accordance with a preferred embodiment of 
the present invention. The associated business rules include the following. Pushing 
Save & Continue user interfaces cause the user to proceed to the next step. Note that 
10 the counties mapping is not saved to the database at this point but are saved in the next 
step. Pushing single arrow user interface buttons cause one selected item to move to the 
other list. Pushing the double arrow buttons causes all the item to move from one list to 
the other. At least one item must be mapped. 

FIG. 71 illustrates a display screen 2880 that a user interfaces with to add region 
1 5 plans and user choose the plan(s) they wish to map to the new region in accordance with 
a preferred embodiment of the present invention. The business rules associated with 
adding region plans includes the following. Users must select a plan(s) that is already in 
the system. Pushing the Back user interface button brings the user back to the Region 
Counties page. Using the single arrow user interface buttons cause one selected item to 
, 20 move to the other list. Using the double arrow user interface buttons cause all the item 
to move from one list to the other. Further, at least one item must be mapped. 

The database actions associated with adding region plans includes when the user 
clicks on the Save user interface button on the Regions plans screen 2880, new records 
are inserted into the CAR_PlanZipcodes table using the effective from/to range and 
25 state entered on the Regions Details screen. 

. FIG. 72 illustrates a display screen 2900 that a user interfaces with to edit 
Region, whereby users can edit an existing region to the system in accordance with a 
preferred embodiment of the present invention. There are three parts to this process, 
including, for example, region details, mapping counties, and mapping plans. The user 
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may choose to edit any one of these by clicking on the item they wish to edit. The user 
can fill in details of information about the region such as carrier and state. The 
applicable business rules include the following: pushing the Save user interface causes 
the information in the form to be saved to the system and the users must pick a state. 
5 The database actions associated with editing the region include the following. When the 
user clicks on the Save user interface button on the Regions details screen, a record 
within the CAR_Regions table for that region is updated within the production database. 
The CAR_PlanZipcodes table within the production database is updated for the given 
region. The effective from/to fields are updated. 

10 FIG. 73 illustrates a display screen 2920 that a user interfaces with to edit the 

counties that maps to the region. The business rules that are associated with editing 
region counties includes pushing the single arrow user interface buttons causes one 
selected item to move to the other list and pushing the double arrow buttons causes all 
the item to move from one list to the other. At least one item must be mapped. The 

1 5 associated database actions include the following. When the user clicks on the Save 
user interface button on the Regions Counties screen one of the following methods is 
used to update the production server: (a) the old records for the given region are deleted 
within the CAR_planZipcodes table. New records are then inserted into the 
CAR_planZipcodes table, (b) or any records within the CAR_PlanZipcodes table that 

20 may no longer be in effect (user removed that county or counties from the region) are v 
left as is. Any counties that were mapped before editing and are still mapped have their 
effective to dates updated. Finally, any new records that need to be inserted would have 
the new effective from and effective to dates. 

FIG. 74 illustrates a display screen 2940 that a user interfaces with to edit 

25 Region Plans. The user edits the plan(s) they wish to map to the region. The business 
rules associated with editing region plans include the following. Users must select a 
plan(s) that is already in the system. Pushing the single arrow user interfaces buttons 
causes one selected items to move to the other list. Pushing the double arrow buttons 
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causes all the item to move from one list to the other. At least one item must be 
mapped. 

The database actions associated with editing region plans includes when the user 

- clicks on the Save user interface button on the Regions Plans screen the following 

5 methods may be used to update the production server: (a) the old records for the given 
region are deleted within the CAR_planZipcodes table. New records are then inserted 
into the CAR_planZipcodes table, (b) any records within the CAR_PlanZipcodes table 
that may no longer be in effect (user removed that plan or plans from the region) are left 
as is. Any plans that were mapped before editing and are still mapped have their 
10 effective to dates updated. Finally, any new records that need to be inserted would have 
the new effective from and effective to dates. 

FIG. 75 illustrates a display screen 2960 that a user interfaces with to do a mass 
update for a region's effective to dates and status. The business rules associated with 
the region activation includes users selecting a region(s) that is already in the system. 
1 5 The database actions associated with the region activation includes when the user clicks 
on the Save button on the regions that have been selected they have their effective to 
dates updated to the new effective to date entered by the user. The records on 
production within the CAR_PlanZipcodes table are updated. 

In accordance with a preferred embodiment of the present invention, users can 
20 view, edit, and add tiers that are mapped to a carrier. The following table describes a 
process to view, edit and add tiers. 



Table 26 



Action * ' ."" «V/\ <-\ 


Screen >^y^J'*j,* 


Description :; ' ; - v;, 0* ^ v ' - 


User clicks on the Tiers folder within 
the tree. 


Tiers List 


Information about the tiers that are currently 
mapped for a given carrier. 


User clicks on a tier number listed in 
the view tiers list. 


Edit carrier tier 
mapping. 


Users can edit a mapping for a tier such as the 
order in which the rates should be used. 


User clicks on the Add Tier action 
node. 


Add Tier 


A new Tier mapping for a given carrier is inserted 
into the system. 


User clicks on the remove tier link. 


Tier List 


Users can delete a tier for a carrier by clicking on 
the delete image next to the tier. 
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FIG. 76 illustrates a display screen 2980 that a user interfaces with to view or 
edit tiers in accordance with a preferred embodiment of the present invention. The 
database actions associated with viewing the tiers includes when the user clicks on the 

Tiers folder under a given carrier, policy type, and state, the information displayed - '~ 

5 within the carrier tiers screen comes from the following tables on production: 
SYS_StateJTierLevel, SYS_TierLevel, SYS_CoverageLevelTierLevel, and 
SYS_CoverageLevel. 

FIG. 77 illustrates a display screen 3000 that a user interfaces with to add a new 
tier/state mapping for a carrier in accordance with a preferred embodiment of the ; 
10 present invention. The database actions associated with adding a tier include when the 
user adds a tier mapping for a carrier/state using the CMS subsystem/a new record is 
inserted into the SYS_State_TierLevel table within the production database. 

FIG. 78 illustrates a display screen 3020 that users can interface with to edit an 
existing tier mapping in the system in accordance with a preferred embodiment of the 
15 present invention. The database actions associated with editing a tier includes when the 
user edits a tier mapping using the CMS subsystem, a record within the 
SYS_State_TierLevel table on the production server is updated. 

In a preferred embodiment, the CMS subsystem includes qualifying events. 
Users can view; edit, and add qualifying events for a carrier. The following table 
20 describes the process for viewing, editing and adding qualifying events. 



Table 27 



Action - ^^y::^ - , - 


Screen ! : ■ ' ■ > - 


Description : - > : 


User clicks on the QE folder within 
the tree. 


Qualifying Events 
List 


Information about the qualifying events for a 
given carrier. 


User clicks on a qualifying event 
listed in the view qualifying events 
list. 


Edit carrier's 
qualifying events. 


Users can edit a carrier's qualifying events; 


User clicks on the Add Qual Event 
action node. 


Add Qualifying 
Events 


A new qualifying event is added for a given 
carrier into the system. 


User clicks on the remove tier link. 


Qualifying Event List 


Users can delete a qualifying event for a carrier 
by clicking on the delete image next to the 
event. 
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FIG. 79 illustrates a display screen 3040 that a user interfaces with to view 
qualifying events. Users can view or edit tiers using this display screen. The database 
actions associated with viewing qualifying events includes when the user clicks on the 
QE folder under a given carrier, policy type, and state, the information displayed within 
5 the qualifying event list screen comes from the CAR_QualEventCodes table on 
production. 

FIG. 80 illustrates a display screen 3060 that a user interfaces with to add 
qualifying events. The users can add a new qualifying event for a carrier in accordance 
with a preferred embodiment of the present invention. The database actions associated 
10 with adding qualifying events when the user adds a qualifying event for a carrier using 
the CMS subsystem, a new record is inserted into the CARQualEventCodes table 
within the production database. 

FIG. 81 illustrates a display screen 3080 that a user interfaces with to edit 
qualifying event. The users can edit an existing qualifying event in the system. The 
1 5 database actions for editing a qualifying event includes when the user edits a qualifying 
event using the CMS subsystem, a record within CAR__QualEventCodes table on the 
production server is updated. 

In a preferred embodiment, the CMS subsystem includes the provision for users 
to view, upload, and import rates into the production system and thereby plan rates. The 
20 following table describes a process for viewing, uploading and importing rates. 



Table 28 



Action 


Screen 


Description 


User clicks on the Plan Rates folder 
within the tree. 


Plan Rates Ust 


Information about the plan rates for a given 
carrier. 


User clicks on the Upload action 
node. 


Upload screen 


Users can upload 1 to 5 excel files containing 
rates at a time. 


User clicks on the import into 
system action node. 


Import Screens 


Once an Excel file is uploaded, the users can 
import the rates into the production system. 


User clicks on the Update Status 
action node. 


Update status 


Users can update the plan rates' status. Note: at 
this time, the status flag must be added to the 
CAR PlanRates table. 



FIG. 82 illustrates a display screen 3100 that a user interfaces with to view plan 
rates for a carrier in accordance with a preferred embodiment of the present invention. 
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FIG. 83 illustrates a display screen 3120 that a user interfaces with to update 
plan rates' activation. The user chooses the plan(s) they wish to update the plan rates' 
status flag and active on date in accordance with a preferred embodiment of the present 
invention. The database actions associated with activation which includes when the 
5 user clicks on the Save user interface button on the plans in the CAR_PlanRates table 
have their status updated to inactive or active. Note: the status flag must be added to the 
CAR_PlanRates table. 

A preferred embodiment of the present invention provides for the upload of plan 
rates. Users can import an Excel sheet of plan rates into the system. Note that screens 
10 are the same however, they are viewed from within the frame of the CMS subsystem. 
The following table provides a process flow of the functionality associated with 
uploading of the plan rates. 



Table 29 



Action ■ \ ' . : ' 


Screen ■< - 


I Description 


User clicks on the Import Plan Rates 
link. 


Upload Plan Rates 
Excel Files 


User chooses up to five Excel files that contains 
the rates as well as carrier and period in which 
the rates are for. 


automatic 


Uploading, please 
wait 


SA-File Upload brings the file to the server and 
saves them to the production drive. 


automatic 


Reading data into 
system 


Program reads Excel file and then inserts records 
into staqe tables. 


automatic 


Verifying data 


Program does checks on data. 



FIG. 84 illustrates a display screen 3140 that a user interfaces with to upload 
15 plan rates files, for example, the user can choose the Excel files that contain the rates in, 
accordance with a preferred embodiment of the present invention. The associated 
business rules include the following. The Excel file, for example, must be formatted 
correctly. The Excel file needs to be accessible to the browser for uploading. Pushing 
the Next user interface causes the program to upload the files, insert the data, and verify 
20 the data. 

The preferred embodiment includes addressing Upload Plan Rates and Imports 
Not Completed in accordance with a preferred embodiment of the present invention. 
The user finishes imports that have already been uploaded onto the server. The 
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following table provides a process flow to address upload plan rates and imports not 
completed. 



Table 30 



Action • . ' ' 


Screen 


Description " : / 


User clicks on the Imports Not 
Completed link or users started 
by Upload Plan Rates. 


Imports 


This screen shows not completed imports. If 
the file(s) were uploaded, read into the 
database, and then verified correctly, the 
status will be ready to continue and the user 
can either continue or delete the import. If 
there was a problem in the process, the user 
will only be able to delete the import. 


User clicked Continue. 


Import Rates Step 1 


User chooses the Carrier and State as well as 
the Effective Dates for the import records. 


User clicked Save & Continue 


Import Rates Step 2 


User maps the Regions found in the Excel 
sheet with the Regions in the database. 


User clicked Save & Continue 


Import Rates Step 3 


User maps the Plans found in the Excel sheet 
with the Plans in the database. 


User clicked Save & Continue 


Import Rates Step 4 


User confirms that the information is correct 
and can then import the data into the Plan 
Rates table. 



5 FIG. 85 illustrates a view of a display screen that a user interfaces with to 

address imports that have not been completed imports. If the file(s) were uploaded, read 
into the database, and then verified correctly, the status is ready to continue and the user 
can either continue or delete the import. If there was a problem in the process, the user 
is able to delete the import. The user maps the regions found in the Excel sheet, for 

10 example, with the regions found in the system. The associated business rules include if 
the file(s) were uploaded, read into the database, and then verified correctly, the status is 
ready to continue and the user can either continue or delete the import, and if there was 
a problem in the process, the user is able to delete the import. 

FIG. 86 illustrates a view of a display screen that a user interfaces with to 

15 address import Rates Step 1 in accordance with a preferred embodiment of the present 
invention. The user chooses the Carrier and State as well as the Effective Dates for the 
import records. The applicable business rules include the following: only active 
Carriers are available in drop down. The users must choose a state. Pushing the back 
user interface brings users back to the Imports list. Pushing the Cancel user interface 
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brings users back to the Plan Rates action page. Pushing the Save & Continue user 
interfaces saves the data to the Imp_Header table and continues to the next step. 

FIG. 87 illustrates a view of a display screen that a user interfaces with to 
address import Rates Step 2 in accordance with a preferred embodiment of the present 
5 invention. The user maps the Regions found in the Excel sheet, for example, with the 
Regions in the database. The applicable business rules include the users mapping every 
region found in the Excel sheet, for example, with one found in the system. Further, 
pushing the back user interface brings users back to the Import Rates Step 1 page. 
Pushing the Cancel user interface brings users back to the Plan Rates action page. 
10 Pushing Save & Continue user interfaces saves the data to the Imp_Details table and 
continues to the next step. 

♦ 

FIG. 88 illustrates a display screen 3220 that addresses the import Rates Step 3 
whereby the user maps the Plans found in the Excel sheet, for example, with the Plans 
in the database. The applicable business rules include the following. Pushing the 
15 Cancel user interface brings users back to the Plan Rates action page. Pushing Save & 
Continue user interfaces saves the data to the Imp_Details table and continues to the 
next step. The users must map every plan found in the Excel sheet, for example, with 
one found in the system. Pushing the user interface back brings users back to the Import 
Rates Step 2 page. 

20 FIG. 89 illustrates a display screen 3240 that addresses the import Rates Step 4 

whereby the user confirms that the information is correct and can then import the data 
into the Plan Rates table. The applicable business rules include Pushing the Import user 
interface to cause the program to move the data to the Plans Rates table. The following 
is the applicable database actions. When the user clicks on the Import user interface 

25 button on the import rates screen the following methods may be used to update the 
production server: The old records for the given region are deleted within the 
CAR_PlanRates table. New records are then inserted into the CAR_PlanRates table. 
The users are given the option of deleting or archiving old plan rates data. 
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FIG. 90 illustrates a display screen 3260 that the user interfaces with to view, 
upload, and edit the information for plan documents on the server. The applicable 
business process is tabulated below. 



Table 31 



Action 


Screen 


Description 


User dicks on the Plan Docs action 
node. 


Tree view 


Users can view current plan docs mapped to a 
plan for a carrier. 


User clicks on the Upload action 
node. 


Upload screen 


Users can upload plan docs(pdf files) mapping 
them to a plan. Users are then brought to an 
edit page for the plan doc information. 


User clicks on the Edit Plan Docs 
action node. 


Edit plan docs 


User chooses the plan doc records they wish to 
edit and clicks on edit. The users then can edit 
the information for those records. 



5 FIGS. 91A and 91B illustrate display screens 3280, 3300 that the users interface 

with to upload and edit the information for plan documents on the server in accordance 
with a preferred embodiment of the present invention. 



Table 32 



Action ' :■ 


Screen 


Description 


User click on the browser buttons 
the select the plans that map to the 
doc. 


Upload Plan Docs 


Users can upload up to ten plan docs at one time 
and need to map the plans to the docs beside 
them. 


Users click upload 




Users now edit the information for the uploaded 
docs. 



The applicable business rules for the upload and edit fiinctionfor plan documents 
includes the following. Any existing document is replaced with the new version. The 
file must be in the pdf format and thus not easy to revise. The uploaded file is renamed 
to PlanNum + .pdf and the file should be copied to a system defined directory, 

FIGS. 92A and 92B illustrate display screens 3320, 3340 that users interface 
with to edit the information for plan documents on the server. The following table 
provides an applicable process, flow. 
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Table 33 



Action 


Screen 


Description 


User dicks on the Edit Plan Docs 
action node. 


Tree view 


Users check the plan doc records they wish to 
edit and the dick the edit button. 


Users dick on the edit button. 


Edit Plan Docs 


Users edit the information for the plan docs and 
push save. 



In a preferred embodiment, the system has an event triggering subsystem that 
functions as a transaction processing subsystem. The event triggering subsystem 
provides a flexible way of building business logic into the CRM business object 
5 subsystems. Custom business logic can be configured to follow CRM actions on CRM 
business objects. CRM Actions include, for example, insert, update, delete and retrieve 
among others. An example customization using event triggering subsystem can be that 
following a CRM insert, the event triggering subsystem creates a forecast on that new 
incident and a work note indicating that this was automatically generated. The event 

10 triggering subsystem is implemented using a trigger definition stored in an (extensible 
Markup Language (XML) file, for example. This complements the fact that the CRM 
uses XML for all of its business objects, properties and methods. 

This subsystem is very flexible and can be extended by the creation of new 
trigger definition files to work with any of the CRM middle-tier business objects. 

15 Trigger definitions are included in the system, for example, for Incident and Task 
business objects. 

The CRM system provides a flexible structure for extending the default business 
logic provided by Onyx, for example. Among other ways of extending the business 
logic, a COM component can be configured to be called by the CRM at a certain point 
20 in the default logic. This is the process by which the event triggering subsystem is 
invoked. 

The event triggering subsystem is implemented in a custom step component 
COM+ component that processes CRM incident actions after they occur. This means 
that the event triggering subsystem can be invoked following an incident insert, update, 
25 delete or any of the several retrieve methods. When the event triggering subsystem is 
invoked, it checks the trigger, definition file (TDF) for a trigger that matches the current 
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CRM action. If it finds such a match, then the event triggering subsystem next performs 
an ordered list of the event triggering subsystem actions as specified in the TDF. The 
event triggering subsystem actions can refer to data from previous event triggering 

— subsystem actions orfrom the CRM action as it carries out its task.- — -.. 

5 In a preferred embodiment, the Trigger Definition File (TDF) Structure includes 

the following. The TDF is housed in an XML document whose root node is an element 
called StepTriggers. The following table defines each element in the document, its use 
and options. Note that under children, {X} refers to exactly X occurrences of a child, 
{X,Y} to between X and Y occurrences inclusive, * to 0 or more occurrences, and + to 
10 1 or more occurrences. 



Table 34 



Element 


Children 


Comments 


StepTriggers 


StepTrigger* 
ExtraData(l) 


This is the root level element. When the event 
triggering subsystem is invoked, each 
StepTrigger child is considered for firing. 


StepTrigger 


TriggerCode{l} 
Master Actional} 
MasterMatch{l} 
Actions {1} 


This element defines a event triggering 
subsystem trigger. A trigger is a set of actions 
that may execute (fire) when the event 
triggering subsystem is invoked. The event 
triggering subsystem uses elements within the 
StepTrigger to decide if the trigger should fire 
and what actions should occur. 


TriggerCode 




The TriggerCode element defines a unique 
code for this trigger. Currently, this must be a 
1 -character code. Currently this is strictly a 
label for the trigger as none of the event 
triggering subsystem functionality references 
this node, but this code is important as an 
identifier when a trigger must fire only 1 time. 
It is up to the event triggering subsystem 
administrator to code StepTrigger properly 
using this code if they wish to create a fire- 
once trigger. See examples below. 


MasterAction 




The element contains a comma-delimited list of 
CRM actions that the parent trigger are valid 
for. For example, if the trigger should fire 
when an incident is inserted or updated, then 
this node should have the value "insert,update" 


MasterMatch 




This node contains an XPATH query which 
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specifies whether or not the parent trigger 
should fire based upon the content of the CRM 
input XML document. See the Onyx 
documentation for information on the form of 
the input to a particular CRM action. Also 
refer to examples below. 


Actions 


Action* 


This element contains all of the Action nodes 
that should be performed for the trigger. 


Action 


Order{l} 
Type{l} 
SkipIfNull {0,1} 
SkipIfBlank {0,1} 
TargetIndex{0,l} 
ReplaceMaps{l} 


The Action element contains all of the 
information necessary to perform one of the 
basic event triggering subsystem actions. See 
the section below for information about the 
different action types currently implemented. 
The results of an action are stored in an 
internal event triggering subsystem action 
record in the form of an XML document. See 
the Order element. The initial calling CRM 
action is stored at index 0. 


Order 




The Order element defines the order in which 
this action should be performed in this current 
set of actions. It also defines the index in 
which this action's results are stored in an 
internal event triggering subsystem action 
record. Actions should be ordered from 1 to 
the number of actions. 


Type 




The Type element defines the Action Type of 
this action. See section below. 


SkipIfNull 


SourceTransform { 1 } 
SourceIndex{l} 


The SkipIfNull is an optional element that can 
cause an action to be skipped. If the action is 
skipped, the results of the action are still stored 
as a blank XML document. The determination 
of when to skip an action uses the Sourcelndex 
child to refer to an action result in the internal 
event triggering subsystem action record. The 
SourceTransform XPATH query is then 
applied to this result document and if the query 
does not return a node, then the action is 
skipped. If the query returns a node or if the 
SkipIfNull element is not present in an action, 
then the Action is not skipped. 


SkipIfBlank 


SourceTransform { 1 } 
SourceIndex{l} 


The SkipIfBlank is an optional element that 
can cause an action to be skipped. If the action 
is skipped, the results of the action are still 
stored as a blank XML document. The 
determination of when to skip an action uses 
the Sourcelndex child to refer to an action 
result in the internal event triggering subsystem 
action record. The SourceTransform XSLT is 
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then applied to this result document and if the 
text value of the transform is blank, then the 
action is skipped. If the transform returns non- 
blank text or if the SkipIfBlank element is not 
present in an action, then the Action is not 
skipped. 


ReplaceMaps 


Map* 


The ReplaceMaps element contains data 
translation Maps that can be used to fill in 
necessary information to perform an event 
triggering subsystem action. 


Targetlndex 




The target index is only used if the action type 
= Update* (except for UpdateForecasts. See 
below). This node then specifies the index into 
the internal event triggering subsystem action 
record. of the item that should be updated. For 
example, if in step 1 and incident was 
retrieved, then in step 2, an Updatelncident 
could specify a Targetlndex of 1 to update that 
incident. 


Map 


Destination{l} 
Source{ 1} 


The Map element is used to fill in data for an 
event triggering subsystem action. The 
Destination child contains information that 
specifies the location in the input XML for the 
event triggering subsystem action. This 
location is where data is mapped. The source 
child defines where to get that data. 


Destination 


DestinationMatch { 1 } 


See DestinationMatch 


Source 


SourceTransform { 1 } 
SourceIndex{l} 


The Source element specifies where mapped 
data comes from. The Sourcelndex child refers 
to an action result in the internal event 
triggering subsystem action record. The 
SourceTransform is an XSLT block that is 
applied at the level of "/" in the resultant • 
document. 


DestinationMatch 




The DestinationMatch child contains an 1 
XPATH query that specifies the location in the 
input XML. for the event triggering subsystem 
action that data should be mapped to. 


SourceTransform 




When used as the descendant of a Map or 
SkipIfBlank node, the SourceTransform is an 
XSLT block that is applied at the level of"/" 
on an XML document. When used as the child 
of a SkipIfNull node, SourceTransform 
contains an XPATH query to a node. See 
section on transforms below. 


Sourcelndex 




The Sourcelndex child refers to an action result 
in the internal event triggering subsystem 
action record. A value of -1 means that the 
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- - - 


- - - 


value in <SourceTransform> is not a transform 
but a constant or function that relies on no 
transformation. See the transformation section 
below. A value of 0 refers to the XML 
document that resulted from the CRM action 
that was performed. Jn other-words, if a CRM - 
incident insert was performed, then index 0 
would contains an XML document as defined 
in the CRM documentation for the output of an 
incident insert. 


ExtraData 


NoEmailList 


The ExtraData element is used to pass global 
values into the trigger mechanism. For an 
example, see the description of the child node 
NoEmailList 


NoEmailList 




The child node NoEmailList allows an 
administrator to specify users for whom the 
email mechanism should not be used. In other 
words, if user A is the one who has caused the 
email action action to trigger (A is logged into 
the CRM and made a change), then if A 
appears in the NoEmailList, no email will be 
sent. Another way of thinking of this is that 
this list maintains a list a people who cannot 
cause the trigger mechanism to send mail. 

This list may contain the special value * to 
indicate that emails should never be sent. 



In a preferred embodiment, the TDF Structure Specification includes the 
following. Since the event triggering subsystem infrastructure can operate on any of the 
CRM middle-tier business objects, different rules can apply to different business 
objects. The rules are contained in the TDF. The TDF to be used is specified in the 
5 configuration of the step extra data in the Onyx Object Designer. This is done by 
specifying the name of the TDF and the name of the middle-tier business object. For 
example, the incident business object sets the following values: 

j9ey?rarto/7F/fe=Incident^ 

The TDF must all be kept in the same location. 
10 In a preferred embodiment, the action Types in the event triggering subsystem 

include a type, expected input, output, and UpdateForecasts and exemplary action types 
without limitation are as follows: RetrieveForecast, RetrieveForecastList, 
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Retrievelncident, RetrieveReminder, RetrievelncidentListEx, RetrieveUser, 
RetrieveWorkNotes, CreateEmail, CreateValueLookup, CreateldLookup, 
CreateActionList, CreateCampaignAction, CreateForecast, Createlncident, 
. . . Create Worknote,-CreateReminder, CreateTask, UpdateForecasts, Updatelncident, and 

5 UpdateReminder. 

Each of the exemplary action types are described hereinafter along with their 
expected input and output XML. RetrieveForecast - this action is used to call the CRM 
forecast retrieve method. RetrieveForecastList - this action is used to call the CRM 
forecast retrieveList method. Retrievelncident - this action is used to call the CRM 
10 incident retrieve method. RetrieveReminder - this action is used to call the CRM 

Reminder retrieve method. RetrievelncidentListEx - this action is used to retrieve a list 
of Incidents based on a search. This does not map to the method documented in the 
CRM documentation. 

The input for the "Input" action is the following exemplary XML structure. 

15 Note only elements that have values set to them are used in the query. 

<incident> 
<ilncidentld/> 
<iSiteld/> 
<iOwnerld/> 

20 <iContactld/> 

<ilncidentCategory/> 

<ilncidentTypeld/> 

<vchAssignedld/> 

<iTrackingld/> 
25 <vchSerialNumber/> 

<vchProductld/> 

<vchDesc1/> 

<vchDesc2/> 

<vchKeyWords/> 
30 <iSourceld/> 

<IStatusld/> 

<iPriorityld/> 

<iCode1/> 

<iCode2/>_ 
35 <ICode3/> 

<iCode4/> 

<chAssignedTo/> 

<IAccessCode/> 

<vchUser1/> 

40 <vchUser2/> 

<vchUser3/> 
<vchUser4/> 
<vchUser5/> 
<vchUser6/> 

45 <vchUser7/> 

<vchUser8/> 
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<vchllser9/> 
<vchUser10/> 
</incident> 

5 The CreateForecast action is used to call the CRM forecast insert method. 

Createlncident - this action is used to call the CRM incident insert method. CreateTask 
- this action is used to call the CRM task insert method. CreateWorknote - this action is 
used to call the CRM worknote insert method. CreateReminder - this action is used to 
call the CRM reminder insert method. UpdateForecasts - this action is used to update 

10 all forecasts on a given owner. This action is different from all other actions in that it 
expects a given format every time it is called. This action is implemented from, for 
example, without limitation, legacy code and it handles non-standard CRM data. Input - 
the following are configured, for example, the <Order> element, and the <Source> 
element and children. Each of the shown <Map> elements is required. OWNER sets 

15 the incident that forecasts should be updated on. PROB sets the close probability that 
the forecasts should be set to. DATE sets the close date for the forecasts. Note, that 
two functions can be passed in the SourceTransform of the Map for the DATE 
parameter. One if NO W(). The other is NULL(). The effect of passing NO W() is to 
update the forecasts with the current date. Passing NULL() passes the NULLED ATE 

20 into the update method. This has the effect of not updating the forecast close date. 
Only the forecast probability would be changed in this case. 

The Output action returns an undefined XML document. Updatelncident this 
action is used to call the CRM incident update method. UpdateReminder - this action is 
used to call the CRM reminder update method. CreateEmail - this action is used to send 

25 an email with a trigger. Input - in a preferred embodiment, this action fills in the 
following message structure. 

<email> 

<to /> 

<from /> 
30 <cc /> 

<bcc/> 

<subject /> 

<textBody /> 
</email> 
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The Output action returns an XML DOM document of the above message filled 
in with whatever values were mapped into it. 

The RetrieveUser action is used to retrieve basic user information from the 
. CRM. Given a user id, the user name and email are filled in. ... . .. 

5 Input: 

<user> 

<userId/> 
<userName/> 
<email/> 
10 </user> 

The Output action returns an XML DOM document of the above message filled 
in with the user information. 

The Retrieve WorkNotes action is used to call the CRM workNote 
retrieveCollection method. CreateValueLookup - this action is used to lookup a string 
15 value in a CRM table given a unique id for that value. 

Input 

<lookup> 

<tableName /> 

<fieldName/> 
20 <searchFieldName /> 

<searchFieldValue /> 

<results /> 
</lookup> 

For example, assume that a table CodeTable contains fields id, and code. Given 

25 an id 123, one can find the associated code value by doing the following: 

tableName = "CodeTable" 
fieldName = "code " 
searchFieldName = "id " 
searchField Value =123 

30 The Output action returns an XML DOM document of the above message filled 

in with the value searched for in the results element. Blank is returned if nothing is 

found. 

The CreateldLookup action is used to lookup an id (long) value in a CRM table 
given a unique string value. 
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Input 

<lookup> 

<tableName /> 
<fieldName /> 

5 . <searchFieldName /> - _ . .... — 

<searchFieldValue /> 
<results /> 
</lookup> 

For example, assume that a table CodeTable contains fields id, and code. Given 

10 a code "ABC", one can find the associated id value by doing the following: 

tableName = "CodeTable" 
fieldName = 

searchFieldName = "code " 
searchFieldValue = "ABC" 

15 The Output action returns an XML DOM document of the above message filled 

in with the value searched for in the results element. 0 is returned if nothing is found. 

CreateActionList - given the way that XSL is used in the event triggering 
subsystem, a transformation can only be done against one XML document at a time. 
For example, if the administrator wants to in action 1 retrieve user information, and then 

20 in action 2 send an email to that user, this is easily done by using a replace map to map 
into the email/to element using a sourceTransform from sourcelndex = 1 . But, if the 
administrator wanted to send the email to two users, they would have to do two separate 
RetrieveUser actions, actions 1 and 2 to get the email addresses, but then there is no way 
to create a source element that combines both of the results. This is because 

25 sourcelndex can only be only number. 

The CreateActionList action allows the administrator to combine the results of 
different actions into a single new action. This new action can then be transformed in a 
map. Input - this action looks to the targetlndex element to determine the constituent 
actions. This list can be a comma separated list of action numbers. Output - this action 

30 returns an XML DOM document. The format of the results will be similar to: 

<actionList> 

<action> 

<orderx/order> 
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<resultsx/results> 
</action> 
</actionList> 

with one or more action elements instantiated with the appropriate results. So in the 

5 above example; if actions 1 and 2 in the trigger are retrieveUser types, arid action 3 is a 

CreateActionList action with Targetlndex = "1,2", then the results of this action appear 

like the following: 

<actionList> 

<action> 

10 <order>l</order> N 

<results> 

<user> 

<userld>dgriffin</userld> 
<userName>Dan Griffin</username> 

15 

<email>dgriffin@valuebenefits.com</email> 
</user> 
</results> 
</action> 

20 <action> 

<order>2</order> 
<results> 

<user> 

<userld>ssalm</userld> 
25 <userName>Shawn Salm</username> 

<emai l>ssalm@y aluebenefi t s . com 

</email> 

</user> 
</results> 
30 </action> 
</actionList> 

In the above example, the administrator could now create a Map with a 
Sourcelndex of 3 that uses both emails. For example: <xsl: value-of 
select=7/action[order=' 1 ']/results/user/email lf />,<xsl: value-of 
35 select= ,t //action[order= , 2 , ]/results/user/emair' /> 

CreateCampaignActioh - this action allows the administrator to add a campaign 
action to a company. 
Input 
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<campaign> 

<iSiteId /> 
<i0wnerld /> 
<iCampaignId /> 
5 <iTrackingId /> 

" <actions> 
<action> 
<actionId /> 
<actionDate /> 
10 <actionOwnerType /> 

<actionOwnerId /> 
<isUnique /> 
</action> 
</actions> 
15 </campaign> 

The following are of note. iCampaignld is read-only by the user. It is filled with 

the id of the existing or newly created campaign for this iOwnerld and iTrackingld. 

ActionOwnerType is used to link an action to another entity in the database. 

ActionOwnerlD is the primary id of the owning entity (currently task or incident). 

20 The isUnique element determines what should take place if the campaign 

already contains the specified campaign action. If isUnique = 1 then a new action is 
created only if one doesn't already exist. If isUnique = 0, then the action is added to the 
campaign regardless of whether one already exists. Output - this action returns a copy 
of the input XML DOM. 

25 In a preferred embodiment, transforms are relied upon heavily in the event 

triggering subsystem to provide a powerful way of mapping data from one XML source 
to another. For example, the <Map> element, the transform is used in the 
<SourceTransform> to build a text value that is placed in the location specified by the 
<DestinationMatch> query. 

30 The process of building the value to map MapValue to a destination includes the 

following. If the value of the <SourceIndex> child is then the value in 
<SourceTransform> is defined as a constant or function. No transformation is 
necessary. MapValue = the value in <SourceTransform>. If the value of the 
<SourceIndex> child is a number >= 0 then the value in <SourceTransform> is defined 



{J:\CLIENTS\ip\082238\3000\3000-101\F0251479.DOC;!} 



082238.3000-101 

-111- 

as a XSLT fragment MapTransform that is used includes an XSLT document being built 
by inserting a MapTransform. 

This XSLT is applied to the XML document found at the location specified by 

. <SourceIndex> in the internal event triggering subsystem Maction record. This allows 

5 the administrator to retrieve an incident in action 1, and then in action 2 transform the 
data from action 1 (<SourceIndex> = 1) into values for action 2. MapValue = the result 
of the above transformation. A code is contained in a file that can be used in the 
transforms. This is useful for, among other things, being able to specify the current 
date. This file is flexible as thus care is taken in any changes that are made to it. 

10 Changes in this file become instantly available to authors of the TDF. No recompilation 
of the event triggering subsystem components is necessary. Note that this file is also 
used to be able to easily alter other components of the CRM. Currently, the event 
triggering subsystem and the Alliance Import are the only ones that access this file. 
Once MapValue has been determined, it is checked for any predefined functions. 

1 5 NOW() : If MapValue contains NOW() anywhere in the text, it is replaced with the 
current date formatted as "YYYY-MM-DD HH:MM:SS". 

An example illustrating the use of the event triggering subsystem includes, 
retrieving and updating an incident in accordance with a preferred embodiment of the 
present invention. The trigger always fires when a sales incident is initially inserted into 

20 the system. The trigger retrieves and then updates the description of the just inserted 
incident. The retrieve is necessary before an update is done because the CRM 
implements record locking that utilizes timestamps on entities. If the incident is not 
retrieved first, the timestamp may not be properly formatted and the update will fail. 
Comments have been inserted inline in the following trigger definition. 



25 



30 



<StepTrigger> 

<!— This trigger will only match a CRM insert action -> 
<MasterAction>insert</MasterAction> 



<!— The MasterMatch XPATH query specifies that this trigger will only fire if the category of the incident 
= 3. 3 is the 

categoryld for Sales Incidents/Opportunities Other types include 2=Service, 1=Finance(Support) - > 
35 <MasterMatch><![CDATA[//incident[norma!ize-space(categoryld) = '3' and]]]></MasterMatch> 



{J:\CLIENTS\ip\082238\3000\3000-101\F0251479.DOC;!} 



082238.3000-101 



-112- 



<Actions> 
<Action> 
<!— 

5 The first action retrieves the incident using the primaryld of the just inserted incident. This is 

stored in index 0 in the 
form: 

_ .. ... . . ^incident -objectType=-" incident" ' actions" insert" -- 

content =" keysOnly " > 
10 <primaryld>158</primaryld> 

</incident> 

As documented in the CRM documentation for the incident insert method output. So the query in 

the 

SourceTransform extracts "158". This value is then placed into the input for a CRM insert 
1 5 method which is of the form: 

<incident objectType=" incident " action^" retrieve" 
content= "keysOnly" > 

<primaryldx/primaryld> 
20 </incident> 

As documented in the CRM documentation for the incident retrieve method. DestinationMatch 
specifies that the 158 

should be placed into the destination XML in the primaryld node. 

- > 

25 <Order>1</Order> 

<Type>Retrievelncident</Type> 
<ReplaceMaps> 
<Map> 

<Destination> 

3 0 <DestinationMatch><! [CDATA[//incident/primary ld]]></DestinationMatch> 

</Destination> 
<Source> 

<SourceTransform><![CDATA[<xsl:value-of select=7/incident/primaryld" /> 

]]></SourceTransform> 
35 <Sourcelndex>0</Sourcelndex> 

</Source> 
</Map> 
</ReplaceMaps> 
</Action> 

40 <Action> 
<!— 

The next action updates the incident retrieved in action 1 whose results are stored in index 1. 
Note that the XML of the 

results of a retrieve (specified by Targetlndex) is used as the input to the CRM incident update 
45 method. There are 

slight differences between the output of the CRM retrieve and the input to the CRM update (for 
example the presence 

of the action- 'update" attribute on the incident element for the update). These differences are 
resolved by the event triggering subsystem and 
50 the administrators job should be to concentrate on the changes to the <incident> child nodes 

— > 

<Order>2</Order> 

<Type>Updatelncident</Type> 

<!— 

55 <Targetlndex> indicates that the results of action 1 should be updated. 

— > 

<Targetlndex>1 </Targetlndex> 
<ReplaceMaps> 
<!— 

60 This map takes the current value of the description! property and appends the text 

"More desc" onto 

the end of it. The result of this transform is placed back into the incident description! 

property.. 

— > 
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<Map> 

<Source> 

<SourceTransform> 
<![CDATA[ 

5 <xsl:value-of select=' , concat(//incident/description1 , 'More desc.y /> 

n> ; 

</SourceTransform> { 

- - <Sourcelndex>1</Sourcelndex> - ...... 

</Source> 

10 <Destination> 

<DestinationMatch><![CDATA[//incident/description1]]></DestinationMatch> 
</Destination> 
</Map> 
</ReplaceMaps> 
1 5 </Action> 
</Actions> 

<TriggerCode>M</TriggerCode> 
</StepTrigger> 

The subsystem includes fire-once triggers in accordance with a preferred 

20 embodiment of the present invention. A fire-once trigger is a trigger that should only 
fire once. While the event triggering subsystem contains no built-in mechanism for fire- 
once triggers, its functionality fully supports the definition of such a trigger. In the case 
of Incidents, for example, a user property is designated as the field which fire-once 
trigger flags are stored. When a trigger is evaluated for firing by the event triggering 

25 subsystem, the <MasterMatch> query must check to see if the <TriggerCode> value is 
set in the user property of the incident. <MasterMatch> must not match Incidents that 
have this value set. The fire-once trigger must also define and action which updates the 
incident so that the user property contains the <TriggerCode>. This heuristic can be 
followed in the construction of more complex trigger-firing mechanisms, for example, 

30 triggers can be repeatable-fire-once. Thus, a trigger (A) can be configured as fire-once, 
but then another trigger (B) can have as one of its actions the step of removing the "A" 
from the user property of the incident, thus allowing trigger A to fire one more time. 
Endless schemes are possible. 

FIG. 93 illustrates a schematic diagram detailing a product support process 3400 

35 in accordance with a preferred embodiment of the present invention. The product 

support process can provide for adding a new carrier per step 3402 that indicates process 
flow between the CMS subsystem 3410 and the reporting subsystem 3412. The product 
support process also allows the addition of new plans per step 3404 that uses the CMS 
subsystem 3414 and a quality control subsystem 3416. Further, additional regions can 
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be added to the integrated system per step 3406. The CMS subsystem 3418 and quality 
control subsystem 3420 assist in the addition of regions to the system. The product 
support process allows for the addition of new rates per step 3408 using the CMS 

subsystem 3422 and the quality control subsystem 3424. - 

5 FIG. 94 illustrates the details of a claim process 3450 in accordance with a 

preferred embodiment of the present invention. The process 3450 includes receiving a 
claim per step 3452 which implicates at least three subsystems in the integrated system: 
the logging subsystem 3460, the EDI subsystem 3462 and the event triggering 
subsystem 3464. The process 3450 continues to the step 3454 of checking the eligibility 

10 of the claimant and the claim received. The reporting subsystem 3466 is interfaced with 
during this step of checking eligibility. The process 3450 then continues to the step 
3456 of adjudicating the claim which can include an internal integrated system 
adjudication and an external adjudication using the partner or vendor portal, for 
example. This adjudication can be electronically processed in its entirety and thus be 

1 5 expeditious. Upon receiving approval for payment after the adjudication, the process 
includes the step 3458 of distributing funds. This step 3458 includes functionality 
provided by the logging subsystem 3460, the EDI subsystem 3462, the event triggering 
subsystem 3464 and the reporting subsystem 3466. 

It should be understood that the programs, processes, methods and systems 

20 described herein are not related or limited to any particular type of computer or network 
system (hardware or software), unless indicated otherwise. Various types of general 
purpose or specialized computer systems may be used with or perform operations in 
accordance with the teachings described herein. 

In view of the wide variety of embodiments to which the principles of the 

25 present invention can be applied, it should be understood that the illustrated 

embodiments are exemplary only, and should not be taken as limiting the scope of the 
present invention. For example, the steps of the flow diagrams may be taken in 
sequences other than those described, and more or fewer elements may be used in the 
block diagrams. While various elements of the preferred embodiments have been 
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described as being implemented in the software, in other embodiments hardware or 
firmware implementations may alternatively be used, and vice- versa. 

It will be apparent to those of ordinary skill in the art that methods involved in 
. . . . . _ the integrated system and method for insurance products may be embodied in a - 
5 computer program product that includes a computer usable medium. For example, a 
computer usable medium can include a readable memory device, such as a hard drive 
device, CD-ROM, a DVD-ROM, or a computer diskette, having computer readable 
program code segments stored thereon. The computer readable medium can also 
include a communications or transmission medium, such as, a bus or a communication 
10 link, either optical, wired or wireless having program code segments carried thereon as 
digital or analog data signals. 

The claims should not be read as limited to the described order or elements 
unless stated to that effect. Therefore, all embodiments that come within the scope and 
spirit of the following claims and equivalents thereto are claimed as the invention. 

15 
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